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FOREWORD 


This document was developed as part of the Integrated 
Programs for Aerospace-Vehicle Design (IPAD) program documentation 
in accordance with contract NASl-14700. Other closely related 
IPAD documents are r 

NASA CR 2981 Reference Design Process (D6— IPAD-70010— D) 

NASA CR 29 82 Product Manufacture Interactions With the 
Design Process (D6-IPAD-700 1 1-D) 

NASA CR 29 83 Product Program Management Systems 
(D 6 -I PAD -70 0 35 -D) 

NASA CR 29 85 IPAD User Requirements (D6-IPAD-700 13-D) 

Special acknowledgement is made of the assistance provided by 
the following contributors to this document; 

Appreciation is extended to the following Boeing contributors 
to this document: G. L, Anderton, K. A. Arbuckle, W- W. 
Braithwaire, H_ A. Crowell, D. D- Meyer, D. D. Redhed, and C. 
W. Wang. Assistance in data modeling methodology was 
provided by W. E- Riimbles- 

Other Boeing personnel who participated in reviews and 
contributed conments and recommendations included: K. G- 
Brauner, C. D. Mounier, C. E_ Plouff, W- E. Wallace, and B. 

R. Yantis. 

The NASA Langley Research Center's Coordinator for this 
document was David D. Loendorf- In addition, assistance in 
the form of conments and recommendations was received from 
the Industry Technical Assistance Board (ITAB) and the NASA 
IPAD Project Office, Langley Research Center. 

Measurements included in this document were not generated on 
the IPAD program; therefore, they are shown here in D. S. 

Customary units. A conversion table (O. S- to SI) is included in 
appendix C. 
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1 .0 SUMMARY 


This document, presents the IPAD design requirements for 
integrated information processing- It is used in ccxi junction with 
CR 2985, the IPAD user requiremaits - Requirements covered by this 
document are summarized as: 

Data Analysis — A data flow model based on a typical aerospace 
design process and a computing resources model representative of a 
large aerospace scientific data processing installation are 
described and analyzed- These models are referenced information 
and serve as a basis for estimating data volume and frequency - 
Parameters should be monitored to indicate vdien the IPAD computing 
system needs adjustment or new resources to improve performance. 

General Data Management — This capability is provided by means of a 
single— source bank of current and historic information accessible 
to all users. This data, which is organized according to the 
structure of the organization that produced it, comprises a 
compauiy resoiirce enabling management to iraprcve its op>erations by 
ensuring common access by all using organizations to a tiniform 
information source that is continuously maintained and updated. 
Provisions are required for generation, storage, retrieval, 
comra\inication, and maintenance of data in a distributed system. 

Information Management — Requirements are specified for management 
of information at the element level as well as the set level, 
including a logical information model and definitions of data 
elements, relationship between data elements, and format of data 
sets- This allows for the retrieval of data elements or sets by 
users and computer programs based on relationships and/or values 
of sp>ecific elements or a range of element values. 

Computer Program Management — This requirement includes a computer 
program library with provision for control of such programs and 
installation into IPAD. Computer programs will be executed as 
IPAD jobs. Each IPAD job will have sxifficient library information 
installed with it to describe the job*s purpose, input/out, and 
capabilities (abstract, keywords, etc.) - 


2.0 INTRODUCTION 


The Integrated Programs for Aerospace-Vehicle Design (IPAD) 
system is envisioned to be a total system oriented to support the 
product design process- The IPAD system design must address 1) 
integrated information processing requirements and 2) user 
reqxiirements , 

Use of ccmmercial products or names of manufacturers in this 
report does not constitute official endorsement of such products 
or mantifacturers, either expressed or implied, by the National 
Aeronautics and Space Administration. 


2-1 SCOPE 

This document presents the integrated information processing 
requirements and is the result of IPAD WBS task 1-3- Document D6- 
IPAD-70013-D presents the system user requirements- Figure 1 
illustrates the relationship of this document to other task 1 
documents - 


2.2 OBJECTIVES 

The objective is to identify: 1) a reference data model; 2) 
management requirements for data storage, retrieval, generation, 
communication, and maintenance; 3) management requirements for 
definition and control of information; and 4) managanent 
requirements for computer programs - 


2.3 APPROACH 

This task was accomplished in accordance with NASA statement 
of work "Development of Integrated Programs for Aerospace Design 
(IPAD) ," 1-15-4934A, Exhibit A, and the technical plan (D6-IPAD- 
70002-P) . The staff assigned to IPAD WBS task 1.3 included 
engineers reassigned from tasks 1.1 (Reference Design Process) and 
1.2 (Manufacture Interactions) and others with special skills in 
computing and geometry definition. In addition, Boeing engineers 
outside the direct contractual work organization were available to 
assist and critique the IPAD work. 

A data flow model is presented in section 4.0. This model 
was constructed using a systenatic modeling method and represents 
the data flow for subsonic transport based on project 1, described 
in section 6.0 of CR 2981 and the meinuf actxiring interactions 
described and qxiantified in CR 2982- This model is for reference 
purposes to quantify the data flow of a typical aerospace product 
development . 
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Section 4,0 also includes a resources model based on typical 
aerospace scientific data processing- The model identifies system 
parameters which may be used by the information (data) bank 
administrator (s) to indicate adjustments required in the IPAD 
system to improve overall performance. They also can be used to 
indicate when additional host system resources, i.e ,, peripheral 
equipment and/or additional computers need to be added. 

The primary IPAD management capabilities are intended to 
support construction and control of an integrated design process 
supported try an information bank and con^uter program library. 
Section 5,0 presents the general data management requirements at 
the level of sets and includes the principal requirenents to 
define and manage a complex process such as the design process 
described in reference 3, the interactions with manufacturing 
described in reference 4 and the interface to product program 
management systems described in reference 5. Section 6.0 presents 
the principal requirements to define and manage information at the 
level of elements. Section 7.0 presents the principal 
requirements to define and manage a large library of computer 
programs used to p>erform the calc\ilations which support design, 
analysis, and the technical definition of the product and its 
component parts . 

It is intended that the management capabilities of IPAD 
provide the general tools required for any company to construct 
its unique design process, information bank, and conputer program 
library. 

Appendix A contains a list of typical questions vrtiich must be 
answered during the progress of a design development cycle of an 
aerospace product. These questions are for reference and are 
based on the subsonic transport, project 1, described in section 
6.0 of CR 2981. 


2.4 BACKGROUND 

An aerospace vehicle manufacturing company develops a stream 
of products heavily dependent on historical experience. The 
complexity of modern products and greater sp>eci a li ration have 
resulted in poor communication between disciplines. Integrated 
systems have been develop>ed to support some interdisciplinary 
technical analysis requirements but with limited consideration for 
management, communication, and control of information. Current 
attenpts to handle this complex communication problem rely heavily 
on human resources. However, as the organization size and the 
volume of the data increase, the reliability of data and ability 
of hximans to maintain control decrease. The critical factors in 
communication are the volume of information being managed, 
controlled, transmitted, or interpreted and the effect of the 
increasing volume on respxatise time. 


- 4 - 



I'^ 

■y, 


The problem is to achieve adequate technical depth within 
reasonable flow times and to consider functional relationships 
required to achieve understanding of the total vehicle. The 
limiting factors in obtaining adequate technical depth lie in 
quick and exact conmiunication of technical information and the 
ability to iterate on the design, including all essential 
disciplines, vmtil the design quality is fully established. 

The reference design process presented in section 6.0 of CR 
2981 described the design process as a system of activity levels 
related to the aerospace product development cycle. These 
activity levels should be interpreted only as a basis for 
definition of the design process- They do not imply a rigid 
design process, either in current existence or proposed for IPAD. 
Some such process is always lased to logically plan and guide the 
work . 


The characterization of the design process by levels is shown 
in figure 2. These levels provided a subdivision of the design 
environment and were used to group related activities into 
integrated design networks for each design level- The existing 
computer programs and required new programs to support these 
networks were identified. (See volume 5 of reference 1.) 

The needs for computer-supported process planning, project 
planning, schedule planning, data and computer program management; 
and for management inf ormation have been identified - The IPAD 
feasibility studies (refs. 1 and 2) showed these needs for the 
aerospace industry- Reference 3 identifies similar needs for 
large civil engineeiring projects with project-type data. The 
computer support is required in the following areas : 

Computer program library 

Data definition and organization 

Data manipulation 

Data integrity and tracking 

Data display (on-line interactive and off-line , both modes in 
previously defined display formats or in formats defined 
interactively) 

Design process definition (level, activity, job} 

Design project definition (task, subtask) 

Project scheduling and critical path identification 
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The capabilities described above must apply to classes of 
problems ranging from information retrieval to ccxnplex engineering 
analysis. It is therefore evident that a correspondingly wide 
range of information structures and data formats must be 
accommodated. One end of the user spectrum might be characterized 
by a request for a project status report showing relationship to 
stored plans, while at the other end an engineering analysis might 
take place involving mathematical operations such as matrix 
manipulation. Specifically, the data base must serve the entire 
class of users involved in the engineering design optimization 
effort. 

In the above examples, the data structure and format required 
to support the project status report would be of a different 
nature than that of the engineering analysis. In the first case, 
the data structure might be a tree or hierarchy that models the 
project organization. The data elements wotxld be formatted 
primarily as text or coded information. Access to the data would 
be directly via the ncimed elenents in the information structure, 
in which case, the user would explicitly address the elements of 
the data base structure. Adequate support of this class of data 
structure is available with existing data management systens 
(software) . 

In the engineering analysis case, the data might be more 
simply characterized as £trrays of floating point nuitbers with no 
specific information structure other than the mathematical context 
in which they are to be used. In this case, the user implicitly 
provides the data structure via the logic of his program. The 
data is made available to the user at the level of files and 
records. There is no currently available data management system 
that concurrently si^ports both types of structures described 
above. The manipulation of this type of data must be performed 
entirely within the user program using conventional input/output 
and file management techniques. Therefore, an objective to 
provide support for both information and mathematical data types 
poses requirements that exceed the state of the art embodied in 
any one data management system. This wide vejriation in data types 
is illustrated in figure 3. The arrows pointing in opposite 
directions indicate a separation between data which is of a 
mathematical nature and that which is of an informational nature. 
Typically, the data contained in the sections labeled PART CDNTROL 
and SUPPORT can be communicated to the iiser in the form of reports 
or in response to interactive queries. The reports and query 
responses must be informative for a wide variety of users ranging 
from high-level managers to warehouse clerks. 

In contrast, data contained in the sections labeled NDMERICAI. 
DEFINITICai cind DESIGN/ANALYSIS is most often used in math^iatical 
algorithms . Most of this data is meaningful only in a 
mathematical sense to those engineers who are immediately involved 
in the overall design process. Even with divergent data types. 
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communication and sharing of data is equally as impcortant in the 
mathematical area as it is in the informational area. It follows 
that the structuring of data for common access is of eqxial 
importance in both areas . 
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Figure 3.— Engineering Data Types 




Historically, large investments have been ntade to support the 
development of informational systems. However, on the 
mathematical side, even though large investments have been made in 
the development of technical computer programs, little or no 
funding has been provided for data base development. 

With the exception of engineering business data systems such 
as those for parts release, the predominent engineering computing 
practice is to obtain printed output of program execution and for 
some larger executions, such as lofting or structural analysis, a 
copy of the output will be stored on disk or tape for 
postprocessing. In the current situaticn, only a limited 
scientific computer data base exists and there is no formal 
organization. There are a few files set up with cpiery capability, 
but these are generally limited to one discipline sixrh as 
propulsion or geometry in design drafting systems. 

The engineeiring computing environment can be characterized 

as : 


Usually one user, one execution 
Limited computing system records 
Evolving to integrated processes 
Using many language processors 

Operating on many conputing system configuraticns 

The significant engineering computing problems can be 
summarized as: 

Difficulty in tracking large quantities of data and programs 

No cajjability to define scientific computing data outside of 
the language processor used to generate the data 

Engineering is not using ccanmon data, resulting in 
duplication and inconsistencies 

Poor computing facilities to transfer engineering data from 
programs to central storage and from central storage to other 
programs 

Data is often not available in a format required by the next 
program, causing need for transformation and resulting in 
schedule slides 

The apparent trends in engineering computing can be 
summarized as continued development of; 
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Integrated systems: 

Involves several disciplines 
No formal data base management 

Limited consideration tor expansion to include 
additional disciplines 

Interactive capabilities: 

Parts release 

Product surface geometry 

Input data prepauration 

Networks of satellite computers, each supporting several 
CAD/CAM work stations 

Central data bases: 

Paits release 
Geometry 

Design/analysis data 

Implementation of distributed conputing system with 

distributed data bases when computer operating systems can 

properly communicate 

Lffective conmunications are required to support the 
continued advancement of engineering computing. Standards in the 
following areas would improve communication of engineering data. 

Data Definition Language — A national standard diould be 
developed for a data definition language to support information 
management within scientific electronic data processing systems. 
The cooperation of the CODASYL Data Base Task Gror^ (ref. 4) 
should be solicited so that the CODASYL standards for a FORTRAN 
oriented data definition language will incorporate the 
reqTiirements to support scientific data process ing- 

FORTRAN — ^A national standard should be developed for a high 
level FORTRAN to reduce machine dependencies. For example, 
explicit precision should be supported so that the conpiler will 
use double or triple precision on machines with various word 
sizes, i.e., 16, 32, 60 bit words- The work done by Control Data 
Corporation (ref. 1, volume IV, appendix C) in support of the IPAD 
feasibility study recommended an IPAD standard FORTRAN IPADF for 
current computers and IPADFV for computers with vector array 
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processing capabilty. IPADF would be a subset of IE?VDFV. "niese 
FORTRAN con 5 >ilers could be written in FORTRAN thus reducing 
machine dependencies. 

Geometry — A national standard should be developed for 
generation, storage and comrununication of three-dimensional bounded 
geometry. This standard should support geometry modeling of 
surfaces and volumes (i.e., total vehicle and component parts) , 
kinematics, and idealization for analysis (i.e. , aerodynamics, 
structures, etc.). The American National Standard Institute (ref. 
5) proposed standard is being developed to support communication 
of geometry data and should be extended to support geometry 
generation and storage . 

Distributed Computing — A national standard is required for 
communications within a distributed computing system \^ere 
computers of different manufactxrre and different word sizes can be 
linked in a common system, control of the system wculd also be 
distributed so that the loss of one computer would result in 
shifting its work to the next available machine in the network 
which can handle the work. 

The National Bureau of Standards work (ref . 6) in support of 
the Integrated Computer Aided Manufacturing (ICAM) being developed 
by the D.S. Air Force will identify existing standards applicable 
to computer aided manufacturing (CAM) . This work should enhance 
development of communication between CAD and CAM systems. 
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3 .0 ABBREVIATIONS 


APU 

AV EFF FL 

ICAM 

IPAD 

IPADF 

IPADFV 

ID 

I/O 

C 

CAD 

CALC 

CAM 

CM 

CODASYL 

CP 

CRUS 

C/U 

DDR 

DE 

DR 

EAMR 

EQ 

KIT CH OUT 

MS 

MSA 


Auxiliary power vmit 
Average effective field lengtli 
Integrated conputer-aided manufacturing 
Integrated Programs for Aerospace-Vehicle Design 
IPAD FORTRAN 

IPAD FORTRAN — Vector processing 

Identification 

Input/output 

Computer (decision) 

Computer-aided design 
Calculated 

Computer-aided manufacturing 
Central memory 

Conference on data systems language 
Central processor 
Computer resources used 
Computer/user (decision) 

Drawing data record 
Data element 
Data relationship 

Engineering advance material release 
Equal 

KRONOS interactive timesharing chara'tters output 

Mass storage 

Mass storage access 
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MSS 


MTO 

OEW 

ORIGIN TYP 

PIN 

RFP 

RUT 

SAMM 

TTY CONNCT 

TTYCT 

D 

WBS 


Mass storage sectors 

Materials technology unit 

Operating empty weight 

Origin type 

Program item number 

Request for proposal 

Resoixrces utilization time 

Systonatic activity modeling method 

Teletype ccrmect 

Teletype connect time 

User (decision) 

Work breakdown structure 


- 14 - 



4.0 DATA ANALYSIS 


The pvirpose of this section is to define a data flow model 
that can serve as an estimate for frequency and "voltme of the data 
flow within a develcpment program, typical of the aerospace 
industry and a typical confuting resources model for scientific 
data processing- These models eire presented as reference 
information only. The data flow model is based on a systematic 
activity modeling method (SAMM) developed by the Boeing Ccanputer 
Services. The irodeiJLng was acccxnplished in a manual mode with no 
computer support. While this method woiild serve to meet the 
requirement to identify data flow paths established in section 
5.3.2, it shoxild not be construed as a user -specified solution for 
the data flow requirement. A rigorous evaluation of data flow 
modeling methods is required prior to selection of a method for 
implementation into the IPAD system. The resources model is 
described in terms of computing parameters which may be used by 
the information (data) bank administrator to indicate adjustments 
to improve overall efficiency. They can also be used to indicate 
when additional host system resources need to be added, i.e., 
peripheral equipment and/or additional computers - 


4.1 DATA MODELING METHOD 


The SAMM data modeling method begins with a top down 
hierarchical decomposition that is represented as a tree or node 
diagram of the type shovm in figure 4. Each node represents a set 
of related activities that may or may not be suj^rted by a 
computer process. The activity model layout shown in figure 5 is 
made for each node- Figure 6 illustrates a format to display 
external data flow at the boimdary of the activity nodel. Ihe 
format establishes a convention for forward input/output and 
feedback input/output - Similarly, figure 7 illustrates a format 
to identify internal data flow. In this example, data flow 
identified as 7 and 8 are forward output and become ii^ut to B and 
C respectively. Data 9 and 10 are feedback to A. Note that B 
has no forward outpxit. Figure 8 illustrates the conbined external 
and internal data flow. In this example, data flow should be 
interpreted as follows : 


Data 1, 2 and 3 
Data 4 and 5 
Data 20 
Data 19 

Data 6-9 and 11-16 
Data 10, 17 and 18 


external forward input 
external feedback ipput 
external forward output 
external feedback output 
internal forward output 
intemaLl feedback output 
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Figure 4.—Hierarchial Decomposition 
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Figure 5.— Activity Model Layout 





FORWARD INPUT 
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Figure 6.— Activity Model External Data Flow Format 



Figure 7.— Activity Model Internal Data Flow Format 
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Figure 8.— Activity Mode! Data Flow and Volume Format 
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The data flow voliime is identified by a number enclosed in 
parenthesis located adjacent to the data ID number. This 
represents the number of 60 -bit words transferred on a conpxiter of 
the CDC 6600 type - In addition, the number of iterations of each 
activity is enclosed in a circle and is estimated for an entire 
development program, i.e conceptual desigm, preliminairy design, 
detail design and production phases of a product dewlopment 
cycle. The type of computing support is identified as 
pred eminently interactive or batch. (It should be assumed that 
data preparation will be interactive for the activities supported 
by batch computing.) 


4.2 EXAMPLE DATA MODEL 

A data model for a subsonic commercial transport has been 
developed based on Project 1 described in section 6.0 of D6-IPAD— 
70010-D. Figure 9 shows the hierarchical decomposition and the 
relationships to the nine IPAD design levels. IPAD levels I, II, 
VII, VIII, and IX were con^leted with only one SAMM model for each 
level. IPAD levels III, IV, V, and VI were deccmiposed into 
additional models. 

The data models together with descriptive information of the 
data flow are presented in figures 10 through 35. The descriptive 
data includes the data identification and title. Also, if 
applicable, a decompositicMi trace shows relationship to the data 
flow identified on the preceding (higher) data model. In 
addition, the origin and destination are shown for data to 
identify lateral data transfers between data models . The data 
flow quantification is in terms of 60 -bit data words and is based 
on the COTiputer program input/output specified in voliime V of 
reference 6 and the quantification of data sets for drawings 
identified in reference 4. 
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Figure 9.— Data Flow Hierarchia! Decomposition (Subsonic Transport) 
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Figure 24.— Develop Preliminary Design Layouts— Level V (Concluded) 
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Figure 27.— Perform Product Level Activities (Concluded) 
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4.3 DESIGN PROCESS DATA CATEGORIES 


An analysis was made of data categories within the design 
process. Figure 36 illustrates these categories. Ihe general 
character of data within each category is described in the 
following sections. 

Product Requirements — Corporate . Corporate requirements for 
new products are based on marketing research, customer orders, 
corporate financial resources, etc. For defense contracts, 
corporate determines what bid proposals will be prepared. The 
parameters for conceptual design projects are size, range, 
operating costs and cost targets for product developnent. The 
data for corporate requirements consist of memoranda, marketing 
reports, general product paraaieters, etc. These represent volumes 
of text, graphs, sketches and drawings vdiich can be cataloged for 
access from files — the infrequency of use may preclude the need 
for other than manual access. 

Product Requirements — Regulatory . Government regulations 
iri 5 )Ose product req[uirements concerning safety, noise, performance, 
etc. This information is in the form of several volumes of 
documentation which are subject to revisions as they are released. 
The design projects must have access to this information, but it 
is not essential that it be available at a moments notice, such as 
at a terminal. It is used to measure requirements at critical 
design reviews - 

Product Requirements — Customer . The military, or Government, 
customer imposes the requirements for a product through a request 
for proposal (RFP) vrfiich describes the mission, cost targets, etc. 
The RFP consists of several documents, generally. Ihe commercial 
custcmer imposes variances from a standard design, usually, such 
as preferences in seating arrangements, instrument groupings, etc. 
These are in the form of Rectification docruments, drawings, 
sketches, color schemes, etc. These are used for the initial 
design and critical design reviews and customer acceptemce. 

Producrt Description — ^Desicm Work Package Descriptions . 

Design work package descriptions are developed to guide all design 
work and to provide a primary interface with all funtional 
departments. The design work packages are the result of a 
coordinated work package team which include team mentoers from all 
involved functional disciplines. Design work packages are used to 
cost design elements and to cpiicikly acxjuaint the personnel 
assigned to the task with all aspects of the task to be 
accoiRlished and the applicable design requirements . They also 
provide early visibility of the component design approach and give 
technology and manufacturing specialists an opportunity to make 
suggestions for cost and weight improvements. 
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The total product hardware is subdivided into discrete 
packages at Work. Breakdown Structure (WBS) levels 4 and 5, and cire 
organized as volumes ot a document. Each voliime is identified by 
a unique program item nvunber (PIN) and contains PIN description 
for the lowest level of the WBS required to insure that the cost 
and development schedules for the work package are clearly 
established. Each work package defines the hardware, schedule, 
critical events, and the established targets for the designer. 
Their purpose is to provide basic information for the design, 
development, and manxrfacture of the product and are used as the 
prime tool for: 

Development of the ccmplete component 

Identifying potential product improvements including cost 

reduction 

An up-to-date design description 

Visibility of concept 

Establishing and tracking targets 

The design work packages serve to define the product until 
the final engineering technical definition is released, e.g., 
drawings, documents, data sets, etc. The work packages consist of 
text and sketches. 

Product Descriptions — Geometry . The geometry of the product 
is represented by several media and methods. One of the primary 
purposes is to communicate the product geometry to nanuf acturing 
in order to fabricate or purchase the veirious components and to 
assemble the product and install the systems. Other users of 
geometry include aerodynamics (for wind tunnel models), structural 
analysis, quality assurance, and product support. 

Loft Geometry is used to generate the shape of the product 
and some off-surface features (e.g., stringer centerlines), 
beginning with rough shapes in preliminary design and developing 
the final product lines which control the conponent geometry. 

Lofts include computer definitions (points, lines and cross 
section logic) and extractions from the definitions which can be 
plotted, printed (coordinate points) or produced on magnetic tapes 
or d i sks. This information can be used ty design for detail 
geometry control and by manufacturing for tool design and 
numerical control input data. 

Detail Geometry is used to define product comp clients, 
systems, assemblies, and installations. These are in the form of 
computer output (plots, tapes, etc.) , dimensioned drawings, and 
undimensioned full-scale drawings. The volume of this information 
has been described in CR 29 82, secrtion 6.0. 
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Product Descxiptions — Materials and Processes . 

Specifications for physical properties of materials that are used 
for specific purposes in the product are used by the designer when 
designating material callouts on the list of materials. These cLre 
also used by procurement vdien ordering the material . 

Process specifications describe requirements for heat treat, 
surface finish, surface treatment, etc. Manufacturing develops 
the production processes that will meet these sped jEL cations, 
based on formability, machineability, etc. 

The material and processes specifications are generally in 
several volumes of handbooks but can reside in a cxinputer data 
base for convenient accessibility by the user of such information. 

Producrt Descriptions — Components . Specif ic:ations for 
purchased ccamponents and those manuf acrtured in— house descrribe the 
criteria for size, strength, weight, funcrtion, and durability. 
These are used to request bids from suppliers and to develop 
criteria for acc:eptance testing of the completed conponents. 

These components may consist of complete systems. 

The specifications are in the form of docruraents for each 
component, consisting of descriptions of the criteria, sketches, 
drawings, and geometric parameters. These documents can be 
adapted to coiiputer storage. 

Manufacturing Information — Production Capabilities . 
Manufacturing provides feedback information bo the design engineer 
to provide guidelines for cost-effective production. The 
information is in various forms (memoranda, inserts to design 
handbooks, etc.) and covers various subjects (rainiraiim comer radii 
for formed sheet metal parts, standard fillet radii for machined 
parts, etc.) _ Cost inpacts may be provided concerning tolerance 
or surface finish, for example. 

This information could be accessed from a computer data base, 
using key words. The designer user would then be able to compare 
various geometries and the associated costs for production. 

Manufacturing Information — Producibility Reviews . 
Manufacturing reviews designs in rough layout form and in final 
form, either informally or as part of a critical design review. 
Ihere is a continxial interaction between the design and 
manufactxiring engineers to develop an efficient design that can be 
produced cost effectively. The information produced informally 
will be incorporated in the design. The review during a critical 
design review is in the form of memoranda and can be documented 
with sketches and recoiamendations, similar to design change 
requests that are initiated after design release. 
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Product Verification — Analyses . Various aspects of the 
product are analyzed, beginning with conceptual design and 
continuing to fineil acceptance by the customer and for 
certification. The analyses include cost, weight, performance, 
systems, euid structxire. Computer programs support the bulk of 
these, although a design engineer may perform some interim 
analyses manually. The output of the analytical conputer programs 
may include printouts, graphs, etc-, and in many cases becomes 
input for other programs. 

Existing computer programs will continue to be used in the 
IPAD environment but will probably be integrated with or 
interfaced to the IPAD system in some manner. 

Product Verification — ^Tests . Various tests are used to 
verify that the product meets the requirements of design intent, 
performance, customer acceptance, etc. These tests utilize 
computer programs to collect and cinalyze the test data. Wind 
tunnel tests are used by aerodynamics early in the design phase 
and are followed by system functional tests, structural static and 
dynamic tests, and Tiltimately by flight tests. There are also 
laboratory tests to determine properties of materials, conponent 
acceptance tests, etc. 

The test results are summarized and documented, using tables, 
graphs, text, etc. This documentation becomes part of the 
historical data for follow-on programs. Some of the test data may 
be used in the analytical programs. 

Reference Material — Standards and Materials . Reference 
information for design engineers is available for standard 
hardware (fasteners) , extrusions, and raw material (sheet, plate, 
etc.) Data on size, strength, and condition is included, as well 
as possible substitutions . This information is primarily in table 
form in several docxment volumes. This data could be stored in a 
computer data base in conjunction with a current inventory, so the 
design engineer could check on availability. This would be 
advcintageoTis when ccnsidering siibstitutlons of material, etc. 

Reference Material — Design Handbooks . Design handbooks 
contain guidelines for design engineers for all aspects of design. 
This requires several volimes of documenation including texts, 
tables, graphs and drawings. The design criteria include fastener 
patterns, forming radii, tolerance analysis, structural analysis 
techniqpies, etc. Much of the information concerns the 
manufacturing feedback with production capabilties and 
limitations. Cost criteria are also discussed. 

Much of the design handbook data is adaptable bo coirputer 
files that can be assessed at a termianl by the vise of key words. 
The information for which computer storage would not be feasible 
could be indexed for a search by the user. 
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Reference Material — Historical Data . Historical information 
is available in many forms from various sources . This information 
concerns experience on existing and past products that can be used 
on new product design. Much of the data has been . relegated to 
archives and can be retrieved in a matter of hours or several 
days. This information may be in the form of drawings and 
documents and test reports. Much of the data aj^ears in the 
handbooks for current use. New information is being gathered by 
product support and spares organizations as actual performance 
experience is documented . 

Historical data is readily usable only when it is organized 
and cataloged for qtiick access by potential users. If a search is 
slow £ind cximber some , it will be abandoned. Here again is a 
potential application for coitputer files of information accessible 
by the design engineer. Classification coding systems are in use 
to index existing parts which may be selected for a current design 
application. D sing manual retrieval methods, classification 
coding systems have been demonstrated to produce 10 percent of the 
pairts required for current design application. This has proved 
very cost effective. 

Management Information — ^Targets . Planning of a new product 
results in targets for costs and schedules, weights, and 
performance. The targets are assigned to program item numbers 
(PIN) which are related to a comprehensive work breakdown 
structure (WBS) . The management of a product line then uses these 
targets to measxire the progress of the attainment of the targets. 

A management information system can be integrated in the IPAD 
system to provide progress reports and isolate problem areas. 

Management Information — ^Actuals . Actual results are 
collected against the target costs and schedules, weights, and 
performance to determine progress. Charts and graphs are produced 
to provide management with this information, on vdxich decisions 
will be based. 

Management Information — Summaries . Target versus actual 
summary reports are used to measure performance, determine problem 
areas and to support critical design reviews. Summaries can be 
provided to tqo management, while more detailed reports are 
provided to lower levels of management for day-to-day progress 
reviews. The results of the summary reports must be available 
both at a terminal and on hardcopy reports. 


4.4 EXAMPLE COMPUTING RESOURCES MODEL 

A computing resources model has been developed to 
characterize typical engineering users. Computing usage 
pcirameters were based on three weeks considered typical of the 
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computing work load for a large scientific computing complex. One 
week was selected from each of three months (March, June, and 
October 1976) . Selective data was extracted from the three weeks 
for the following work groupings: 

Structures staff 

All other staffs (aerodynamics, weights, etc.) 

Detail design structure 
All other detail design 
Preliminary design 
All other engineering 
Total t ali engineering 

Sixteen basic parameters were evaluated for each of the above 
work groups. A logarithmic or linear distribution was plotted for 
each parameter. The distributions were based on the nximber of 
jobs which fall into a specific range, such as central processor 
seconds having an upper limit of 1 sec, 2 sec, 4 sec, 8 sec, etc. 
The following is a list of the parameters evaluted: 

CP SEC (central processor seconds) 

RUT SEC (resources utilization time) 

CM UNITS (central memory units) 

MS ACCESS (mass storage access) 

MS SECTORS (mass storage sectors) 

KIT CH OUT (KRQNOS interactive timesharing character output) 

TTY CONCT (teletype connect time) 

CALC CRUS (calculated computer resource \inits) 

CP/RUT (ratio of central processor seconds to total seconds 
of resources used) 

MSS/MSA (ratio of sectors of data per each disk request) 

CRUS/TTYCT (ratio of resources used per second of terminal 
connect time) 

AV EFF FL (average effective field length) 
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CP/TTYCT (ratio of central processor seconds used per second 
of terminal connect time) 

MSA/TTYCT (ratio of disk requests per second of terminal 
connect time) 

MSS/TTYCT (ratio of mass storage sectors obtained per second 
of terminal connect time) 

ORIGIN/TYP (origin type i.e., local batch, remote job entry 
or timesharing) 

The log sum distribution was also plotted for several 
piurameters. The plotted data were further divided iy 1) 
timesharing jobs, 2) batch jobs and 3) all jobs . This generated a 
total of 245 plotted distributions, i.e., 35 distributions for 
each of the seven work grcwpings. Figures 37 throuc^ 58 show the 
35 distributions for the total of all engineering work. The work 
represented by these distributions is typical of the commercial 
airplane scientific comptrting environment and would be similar for 
military aircraft. The work includes preliminary design, a major 
product development effort for a new subsonic commercial 
transport, a major product development effort for a derivative 
subsonic commercial transport, and sustaining for four subsonic 
ccmtinercial airplanes in current production. The work does not 
include engineering business systems such as parts release. The 
complete distributions are contained in computer listing Sl-L-0001 
(ref. 7) . Tables 1 through 4 show a comparison of the mean value 
for each of the 16 parameters and their standard deviation. These 
tables characterize the average or typical timesharing and batch 
users. The sixteen parameters used in the analysis of confuting 
resources should be considered examples and are reference data to 
aid the computing staff in selecting the parameters to be used to 
meet the requirements for confuting system performance, 
monitoring, and control specified in section 5. 3.5. 3. It may be 
necessary during the computing day to make adjustments in basic 
ccMiputing system resources available for jobs such as central 
memory, central processor time slice, etc., in order to maintain 
acceptable overall ^stem response time. 
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Figure 37.— Total Engineering Time-Sharing Jobs— 
Distribution of CP Sec (Units— Sec) 
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Figure 38.— Total Engineering Time-Sharing Jobs— 
Distribution of RUT Sec (Units— Sec) 
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Figure 39.— Total Engineering Time-Sharing Jobs— 

Distribution of CM Units (Units— 64k Sectors) 


67 



MS ACCESS 

UPPER 

LIMIT 

NO. 

JOBS 

% 

5 

9 

0 

10 

5 

0 

20 

767 

11 

40 

1562 

O':! 

80 

1384 

19 

160 

1095 

15 

320 

930 

13 

640 

752 

10 

1280 

425 

6 

2560 

200 

3 

5120 

79 

1 

10240 

17 

0 

20480 

5 

0 

40960 

0 

0 

81920 

0 

0 

163840 

]? 

0 


xxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxx 

xxxxxxxxxxxxx 

xxxxxxxxxx 

xxxxxx 

XXX 

X 


MS ACCESS 

UPPER 

LIMIT 

TOTAL 

MS 

ACCESSES 

% 

5 

22 

0 

10 

42 

0 

20 

13347 

1 

40 

46581 


80 

78627 

4 

160 

124747 

6 

320 

213407 

10 

640 

339699 

16 

1280 

377074 

17 

2560 

354103 

16 

5120 

270084 

12 

10240 

112836 

5 

20480 

77303 

4 

40960 

0 

0 

81920 

0 

0 

163840 

172778 

8 


,x 

*xx 

,xxxx 

♦ xxxxxx 
♦xxxxxxxxxx 
♦xxxxxxxxxxxxxxxx 

♦ xxxxxxxxxxxxxxxxx 
♦xxxxxxxxxxxxxxxx 
♦xxxxxxxxxxxx 

♦ xxxxx 

♦ xxxx 


♦xxxxxxxx 


Figure 40.— Total Engineering Time— Sharing Jobs— 

Distribution of MS Access ( Units— Accesses) 
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Figure 41.— Total Engineering Time-Sharing Jobs— 

Distribution of MS Sectors (Units— Sectors) 
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Figure 42. — Total Engineering Batch Jobs— 

Distribution of CP Sec (Units— Sec) 
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Figure 43. — Total Engineering Batch Jobs— 

Distribution of RUT Sec (Units— Sec) 
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Figure 44.— Total Engineering Batch Jobs— 

Distribution of CM Units (Units— 64k Sectors) 
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Figure 45.— Total Engineering Batch Jobs— 

Distribution of MS Accesses (Units— Accesses) 
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Figure 46. — Total Engineering Batch Jobs— 

Distribution of MS Sectors (Units— Sectors) 
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Figure 47.— Total Engineering Time— Sharing Jobs— 

Distribution of KIT CH OUT (Units— Characters) 
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Figure 48.— Total Engineering Time-Sharing Jobs— 

Distribution of TTY CONNCT (Units— Sec) 
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Figure 49.— Total Engineering Jobs— 

Distribution of CALC CRUS (Units— Crus) 
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Figure 50. — Total Engineering Jobs— 
Distribution of CP/RUT 
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Figure 51.— Total Engineering Time-Sharing Jobs— 
Distribution of MSS/MSA 
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Figure 52.— Total Engineering Batch Jobs— 
Distribution of MSS/MSA 
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Figure 53.— Total Engineering Time-Sharing Jobs— 
Distribution of CRUS/TTYCT 
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Figure 54.— Total Engineering Jobs— Distribution of AV EFF FL (Units— OCTAL) 
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Figure 55. — Total Engineering Time-Sharing Jobs— Distribution of CP/TTY CT 


83 



MSA/TTYCT 




UPPER 

NO. 



LIMIT 

JOBS 

% 


.005 

13 

0 

♦ 

.010 

71 

1 

.X 

.020 

254 

4 

.xxxx 

.040 

620 

9 

.xxxxxxxxx 

.090 

1280 

18 

. xxxxxxxxxxxxxxxxxx 

. 160 

1833 

25 

.xxxxxxxxxxxxxxxxxxxxxxxxx 

.320 

1647 

23 

. xxxxxxxxxxxxxxxxxxxxxxx 

.640 

1011 

14 

.xxxxxxxxxxxxxx 

1.280 

400 

6 

.xxxxxx 

2.560 

87 

1 

.X 

5.120 

13 

0 

♦ 


Figure 56.— Total Engineering Time-Sharing Jobs— Distribution of MSA/TTY CT 
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Figure 57.— Total Engineering Time-Sharing Jobs— Distribution of MSS/TTY CT 
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Figure 58.— Total Engineering Jobs— 
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Table 1.— Computing Resources Utilization-Typical Technology Staff 


WORKGROUP 
\ PROCESSING 
N. TYPE 

STRUCTURES STAFF 

ALL OTHER STAFFS 

TIME SHARING 
JOBS 

BATCH 

JOBS 

ALL 

JOBS 

TIME SHARING 
JOBS 

BATCH 

JOBS 

ALL 

JOBS 

PARAMETER 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

CP SEC 

7.91 

20.73 

93.63 

267.65 

— 

— 

15.28 

55.57 

108.85 

403.17 

— 

— 

RUT SEC 

17.66 

46.11 

201.05 

479.46 

— 

- 

26.30 

76.61 

166.76 

577.37 

— 

- 

CM UNITS 

6.13 

24.19 

109.47 

317.61 

- 

- 

9.36 

32.96 

92.66 

416.36 

- 

- 

MS ACCESS 

234 

631 

2,135 

5,859 

- 

— 

283 

658 

1,036 

4,451 

— 

— 

MS SECTORS 

4,042 

14,987 

35,200 

127,917 

~ 

- 

4,422 

14,082 

18,560 

96,776 

- 


KIT CH OUT 

4,384 

5,778 

- 

- 

- 

- 

6,994 

10,289 

- 

- 

- 


TTY CONCT 

1,226 

1,440 

- 

- 

- 

- 

1,555 

2,172 

- 

- 

- 


CALC CRUS 

- 

- 

- 

- 

10.69 

32.37 

- 

- 

- 

- 

7.85 


CP/RUT 

- 

- 

- 

- 

.3527 

.2421 

- 

- 

- 

- 

.3814 


MSS/MSA 

15.3 

9.4 

18.4 

16.5 

- 

- 

15.7 

18.2 

15.9 

10.6 

- 


CRUS/TTYCT 

.002 

.001 

- 

- 

- 

- 

.002 

.001 

_ 

_ 

- 

- 

AV EFF FL 

- 

- 

_ 

- 

51.025 

37,256 

- 

— 

- 

- 

42,737 

33,332 

CPATYCT 

.006 

.011 

- 

- 

- 

- 

.007 

.016 

- 

- 

- 

- 

MSAATYCT 

.244 

.343 

- 

- 

- 

- 

.227 

.279 

- 

- 

- 

- 

MSS/TTYCT 

3.692 

6.533 

- 

- 

- 

— 

3.193 

4.328 

- 

- 

- 

- 

ORIGIN TYP 

1,658 

- 

2,348* 

- 

4,006 

- 

4,260 

- 

3,736* * 

- 

7,996 

-■ 


*777 RJE & 1 571 LOCAL •*689 R JE 8t 3,047 LOCAL 






Table 2.— Computing Resources Utilization— Typical Detail Design 


WORKGROUP 
\ PROCESSING 

DETAIL DESIGN STRUCTURES 

ALL OTHER DETAIL DESIGN 

N. TYPE 

TIME SHARING 
JOBS 

BATCH 

JOBS 

ALL 

JOBS 

TIMESHARING 

JOBS 

BATCH 

JOBS 

ALL 

JOBS 

PARAMETER 

MEAN 

STD. 
DEVI A. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

CP SEC 

11.09 

22.02 

36.15 

80.23 

- 

- 

37.00 

85.93 

45.23 


83.13 

- 

- 

RUT SEC 

24.63 

43.13 

74.82 

133.04 

- 

- 

132.04 

421.56 

65.02 


105.61 

- 

— 

CM UNITS 

10.63 

21.19 

38.30 

61.99 

- 

- 

71.72 

251.56 

38.70 


66.74 

- 

— 

MS ACCESS 

316 

803 

650 

1,118 

- 

- 

4,630 

18,015 

684 


2,209 

- 

- 

MS SECTORS 

5,556 

11,488 

12,152 

21,768 

- 

- 

10,960 

25,779 

5,387 


6,411 


— 

KIT CH OUT 

5,479 

6,971 

- 

— 

- 

- 

7,223 

12,769 

- 


- 

- 

— 

TTY CONCT 

1,508 

1,744 

- 

- 

- 

- 

2,218 

2,999 

- 


— 

- 

- 

CALC CRUS 

- 

- 

- 

- 

4.15 

6.42 

- 

- 

- 


— 

8.88 

26.42 

CP/RUT 

- 


_ 

- 

.3265 

.2404 

- 

__ 

- 


— 

.3717 

.2926 

MSS/MSA 

20.6 

21.9 

25.0 

25.9 

- 

_ 

24.1 

24.6 

19.2 


12.3 

- 

- 

CRUS/TTYCT 

.002 

.001 


- 



.003 

.003 

- 


- 

— 


AV EPF FL 

_ 

- 

— 

- 

50,642 

35,221 

— 

— 

- 


- 

62,061 

46,312 

CP/TTYCT 

.006 

.012 

— 

- 

- 

- 

.011 

.020 

- 


^ * 

- 

— 

MSA/TTYCT 

.221 

.282 

_ 

- 

_ 

- 

.347 

.710 

- 


- 


— 

MSS/TTYCT 

3.593 

3.996 

- 

- 

- 

- 

4.376 

4.392 

— 


- 

- 

- 

1 ORIGIN TYP 

832 

- 

541* 

- 

1,373 

- 

46 

- 

60* 

• 

- 

- 

104 

- 


*247 RJE & 294 LOCAL *14 RJE & 46 LOCAL 




Table 3.— Computing Resource Utilization— Typical Preliminary Design and AH Other Engineering 


00 

VO 


WORK GROUP 
PROCESSING 
TYPE 


PARAMETER 


PRELIMINARY DESIGN 

ALL OTHER ENGINEERING 


TIMESHARING 

BATCH 

ALL 

TIMESHARING 

BATCH 

ALL 

JOBS 

JOBS 

JOBS 

JOBS 

JOBS 

JOBS 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 



14.91 

59.56 

94.83 

216.73 

- 

- 

7.23 

16.23 

102.97 

252.34 

_ 

_ 

27.01 

86.95 

241.75 

567.88 

- 

- 

18.03 

31.36 

152.85 

260.10 

— 

_ 

10.47 

35.94 

150.91 

674.80 


- 

8.81 

18.21 

77.94 

116.03 

_ 


308 

932 

2,250 

5,042 

- 

- 

141 

275 

1,016 

1,214 

— 

— 

4,625 

9,754 

58,472 

176,913 

- 

- 

5,553 

12,390 

19,963 

19.271 

— 

- 

5,639 

6,811 

- 

- 

- 

- 

5,603 

7,002 

- 

— 

— 

— 

1,516 

1,519 

- 

- 

- 

- 

1,660 

1,940 

- 

— 

— 

- 

- 

- 

- 

- 

10.51 

44.98 

- 

- 

- 

- 

6.34 

11.18 

- 

- 

- 

- 

.3383 

.2499 



- 

- 

.3305 

.2556 

16.3 

7.6 

19.9 

18.6 

- 

- 

34.6 

54.3 

25.2 

17.5 

- 

— 

.002 

.002 

- 

- 

- 

- 

.002 

.001 

- 

- 

- 

- 

- 


_ 

- 

44,575 

34,372 

- 

- 

- 

- 

53,244 

35,765 

.008 

.020 


- 

- 

- 

.004 

.010 

- 

- 

- 

— 

.246 

.288 

- 

- 

- 

- 

.159 

.174 

— 

- 

— 

— 

3.714 

4.386 

- 

- 

- 

- 

3.220 

3.599 

- 

— 

— 

— 

321 

- 

244* 

- 

565 

- 

117 

- 

80** 

- 

197 

- 


CP SEC 
RUT SEC 
CM UNITS 
MS ACCESS 
MS SECTORS 
KIT CH OUT 
TTY CONCT 
CALC CRUS 
CP/RUT 
MSS/MSA 
CRUS/TTYCT 
AV EFF FL 
CP/TTYCT 
MSA/TTYCT 
MSS/TTYCT 
ORIGIN TYP 


*54 RJE & 190 LOCAL 


*27 RJE & 53 LOCAL 
































Table 4.— Computing Resource Utilization— Typical Engineering 


WORKGROUP 

PROCESSING 

TYPE 

PARAMETER 

TOTAL ALL ENGINEERING 

TIMESHARING 

JOBS 

BATCH 

JOBS 

ALL 

JOBS 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

MEAN 

STD. 

DEVIA. 

CP SEC 

13.09 

46.84 

97.04 

337.60 

— 

_ 

RUT SEC 

24.67 

75.33 

172.71 

519.11 

— 

— 

CM UNITS 

9.18 

36.05 

95.48 

378.16 

— 

— 

MS ACCESS 

301 

1,597 

1,413 

4,840 

— 

— 

MS SECTORS 

4,532 

13,953 

24,926 

109,133 

— 

— 

KITCH OUT 

6,136 

8,973 


— 

_ 

_ 

TTY CONCT 

1,478 

1,960 

— 

— 

— 

— 

CALC CRUS 

— 

— 


— 

8.38 

32.44 

CP/RUT 

- 

- 

_ 

— 

.3656 

.2631 

MSS/MSA 

16.6 

18.2 

17.7 

15.1 

— 


CRUS/TTYCT 

.002 

.001 

— 

_ 

— 

_ 

AV EFF FL 

- 

— 

— 

— 

45,41 1 

35,061 

CP/TTYCT 

.007 

.015 

— 

— 

— 


MSA/TTYCT 

.230 

.299 

— 

— 

— 

_ 

MSS/TTYCT 

3.384 

4.888 

— 

— 

— 

— 

ORIGIN TYP 

7,232 

- 

7,009* 

- 

14,241 

- 


*1,808 RJE & 5,201 LOCAL 
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5.0 GENERAL DATA MANAGEMEOT 


This section describes the general principles of how IPAD 
should support data management and the definition and control of 
data generated during the execution of complex computer processes. 


5.1 DATA STORAGE 

An IPAD information bank is required and shall consist of all 
data ^ich can be stored and retrieved by individuals or computer 
programs utilzing the IPAD system. It is envisioned that the 
orgcinization of the information bank will be the responsibility of 
an information bank administrator (s) . Information administration 
is consideired to include authority over data integrity and 
security and the responsibility for the overall efficiency of the 
information bank. NASA CR 2985 contains additional requirenents 
for system administration and information bank administration. 

The following or an equivalent hierarchial data storage modeling 
capability shall be provided to support data partitioning within 
the IPAD information bank (these items will be described in 
reverse order) : 

Information bank 
Data area 

Data set 


5.1.1 DATA SETS 

A data set is defined to be a named unit of data and shall be 
the primary means for data conimunication within IPAD cund between 
IPAD and remote systems- All occurrences of data in the 
information bank shall exist as values in data sets - A data set 
may contain a single data value or an arbitrary collection of 
values . The content of the data set may or may not be defined to 
IPAD. Section 6.0 contains specific requirements for definition 
of the contents of data sets - 

A data set shall consist of two general items: a header 
identifing the source of the data and the occurrence of data 
values it contains. (Note: Ihe word occurrence is used throughout 
this dociment to indicate that data values exist in a data set.) 


5.1.2 Data Areas 


A data area is defined to be a named collection of data sets 
and/or data areas and shall be the primary means to partition the 
infonaation bcink into a logical organization such as the exan 5 >le 

-Si- 


ll 


information bank organization described in section 5. 1.3.2. The 
need to partition or split data by responsibility and other 
criteria is noted by many authors. References 3, 8, 9 and 10 are 
examples . 

A data area shall consist of tvK) general items ; a dictionary 
or index describing what the area may contain and the actual 
occurrences of data sets it contains. 

Each active user in IPAD will have a special siibtask data 
area, which vd.ll function as a private working data space. All 
data generated by actions of a user is automatically placed in the 
user's working area. Separate action must be specified to make a 
given data set a member of more than one data area. (See sections 
5.2.1 and 5. 3. 2.1.) 


5.1.3 INFORMATION BANK 

The information bank is defined to be the domain or 
collection of all data areas defined to IPAD. The following 
illustrates how am IPAD information bank may be organized. 


5-1. 3.1 Nested Data Areas 

The use of nested data areas will allow the information bank 
administrator (s) to view the total information bank as having 
regions and subregions made up of many nested data areas 
containing many data sets . 

Figure 59 illustrates a method which can be used to create a 
logical organization for an IPAD information bank. The following 
describes the elements of this organization technique. 

Information Bank — An IPAD information bank consists of the 
collection of all data areas which are defined to the IPAD 
system. 

Region — A region consists of a collection of all data areas 
related to one major functional organization using IPAD. 

Subregion A subregion consists of a collection of all data 

areas related to one discipline within a major functional 
organization. 

Work Type — A work type consists of a data area which contains 
a collection of related data sets. 
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Figure 59. —Method to Organize Information Bank 

















Data Set — A data set consists of a collection of data values 
that are input or output for a problem solved within IPAD or 
received from a system remote to IPAD- {See section 5.4.) 


5. 1.3. 2 Example Information Bank Organization 

Large engineering organizations are usually divided into 
groups of specific technical or functional disciplines. These 
groups are organized into design development projects and staffs 
which develop technology and perform analysis. All of these 
groiips have large quantities of information and data stored in 
direct access devices, tape, film, filing cabinets, etc. Much 
duplication occurs and results in some data not being current, 
however, it may still be in use. To correct this situation it is 
desirable to develop a single-source information bank accessible 
to all having a use for the data but with data modification 
capability limited to those having responsibility for the data. 

The purpose and primary advantage of a single— source 
information bank is to provide the capability to control and 
manage data as a conpany resource and to provide imparoved product 
configuration control by eliminating redundant data from the 
technical definition of the configuration tinder development. 

A logical organization is required to partition the 
information bank so that it can be controlled. Logical 
relationships promote the grouping of data into sets for 
convenience of handling. Control of access to specific data both 
for information or nodification will promote' grouping of data sets 
into data eireas . Reporting requirements and program input/output 
will also promote grouping of data sets into data areais. 

A hierarchy of relationships based on the logic of section 
5. 1.3.1 can be established as a model to organize an integrated 
information bank into data areas- Figure 60 shows the highest 
organization of an example information bank and establishes 
relationships to the major division of information development 
within a product-oriented program. Each of these data areas 
logically can be considered a region of the information bank. 

The areas (regions) labeled product configuration design and 
product configuration analysis are highly dynamic in the early 
stages of a product development effort, and a unique occurrence of 
data sets in these areas will apply to each unique configuration 
under investigation. By contrast, all other areas contain data 
sets which are generally stable over long periods of time and 
shoxild only require small cheinges for correction or update. 

Figure 61 shows nested data areas for configuration design. 
Each of these data areas can logically be considered a subregion 
of the information bank that is related to a discipline or set of 
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disciplines. These siibregions Ccin be further divided to contain 
the data sets related to a work type or component part of the 
product . 

As previously stated, the configuration design area of the 
information bank is highly dynamic, especially in conceptual 
design and in the early stages of preliminary design. This area 
should accommodate five to ten configurations on-line and have 
provisons for back-up storage for up to 200 previously defined 
configurations. The capability should be provided to bring 
selected configurations from back-up storage to online status 
within a maximam of 24 hours and at a low computing cost. The 
amount of data for each of these configurations will vary 
depending on the level of design and analysis completed. (See 
section 6.0 of Oi. 2985 for a description of the levels of the 
design process.) 

As in figure 61 for configuration design, and as a further 
illustration of the type of organization required, figures 62 
through 65 expand the configuration analysis, configuration 
evaluation, procedural information, and management information 
regions into their nested data areas. 


5.1.4 DATA STORAGE CONTROL 

Control over the data is required in order to maintain its 
integrity. Every user wants to be assured that modification of 
data can only be made by its owner or by a designated person- The 
consequences of lack of control become more serious as data 
becomes accessible to more people. 

Another aspect of data control is associated with the quality 
of the data itself. In addition to change control, there needs to 
be provision for "signing off" data under certain circumstances - 
Today this is generally hcindled by memos, i.e., no computerized 
action. Some analogous mechanism will have to be present for the 
computer stored data, as approval categories such as 
"preliminary," "checked," and "approved," are required. The IPAD 
system will provide for several categories of approval, however, 
it shall be possible for each company using IPAD to change the 
approval identification names and the number of approval 
categories . 
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Figure 60,— Example Information Bank— Directory 
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Figure 61.— Example Information Bank— Configuration Design Region 
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Figure 62.— Example Information Bank— Configuration Analysis Region 
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Figure 63.-Example Information Bank-Configuration Evaluation Region 
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Figure 64.— Example Information Bank— Procedural Information Region 
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Figure 65.-Example Information Bank— Management Information Region 











5. 1-4.1 Responsibility for Data Control 


In general, responsibility for data sets lies with those 
responsible for the associated data area. Hiis means that all 
data sets in a given data area are the responsibility of the 
person or persons in charge of the data area. The responsibility 
is for : 

Change control: 

Who can insert new data 
Who can make changes to existing data 
Tracking changes which are made 
Quality 

Data labels are accurate 

Data values are verified and "signed off" 


5. 1.4.2 Establishment of Data Change Controls 

For change control, the system must guarantee that data set 
content changes cause a change in data set identification. Two 
classes of identification changes may take place: 

(1) Insertion of a new name 

(2) Qualification of an existing name ty a version 
number 

Class (1) is always at the user's discretion. Class (2) is a 
possible user choice, but the system must have a systematic means 
of assigning version numbers. When data is altered, the user must 
select one of these options for recording in the header the fact 
that the new data set is different from the old. 


5. 1.4. 3 Data Identification 

An additional area of data control is the identification of 
data sets when they are generated- There are three basic ways 
data can be inserted into the information bank: 

From an external source under user direction 

From a system function (executed under control of the 
user) 
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From a job in the IPAD computer program library 
(executed under control of the user) 

In the first case the user will wish to identi:^ data by some 
reference to the origin of the data (airplane model number, 
configuration number, case nvnnber, etc.) . This label is totally 
arbitrary from the system's staindpoint, although such labels are 
expected to be instances of defined data elements (see section 
6 - 0 ) . 


In the second and third cases, desirability for complete and 
accurate record keeping of the origin of computer— generated data 
dictates computer control of a portion of the label associated 
with computer-generated data. The intent is that every data set 
in the information bank carries with it sufficient identification 
to guarantee precise knowledge of its origin. In general, this 
mecins that identification of all input data and computer programs 
contributing to the generation of a data set must be kept- If, 
for the entire IPAD system, this is optional, there must be a 
mechanism to make it mandatory for specified data sets (see 
section 5-3-7) . 


5-2 DATA RETRIEVAL 

Controlled retrieval of data from the information bank shall 
be supported for access by users and by computer programs. 


5.2.1 ACCESS TO DATA SETS 

Data sets stored in the data area of a functional 
organization will obviously be accessed by users and computer 
programs belonging directly to that functional organization. 
However, it shall also be possible for users and conputer programs 
from other functional organizations to access the seme data sets 
subject to assigned limitations (see section 5.2.3) . 

Ownership of data sets can be visualized in a hierarchial 
way; however, access to data may be visualized as a network that 
permits lateral relationships between data sets . For example, in 
figure 61, the data area "wing" under subregion general 
arrangement would contain four data sets: planform, thicknessform, 
twistform, and camberform- Also, the data area "wing" under 
subregion structural arrangement would contain data sets to 
describe the wing centerline structxire, e.g., spars, ribs, etc. 

It should be noted in these exanples that the data for structural 
arrangements would not stand alone, i.e., the wing stiructural 
arrangement data sets plus the wing planform data set would be 
reqxiixed to fully describe the structural arrangement and how it 
relates to the wing- This in^lies that a combination tree/network 
may be required, the tree to identify ownership and the network to 
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permit the required access relationship. IPAD should peirrait the 
user to display the arrangement data sets and the planform data 
sets by specifying the structurcil arrangement data sets only. 


5.2.2 DATA SET QUERX 

The requirements stated in this section apply to query at the 
data set level- See section 6.5 for query requirements on the 
content of data sets. Query of data sets w^ill be based on data 
contained in a header. The header data will consist of data 
generated by the IPAD system and data supplied by the user. The 
data generated by the IPAD system is identified in section 5.3.7 
and consists of records identifying the source of the data set. 

The header data supplied by the user identifies what the data set 
represents, i.e., airplane model number, wing planform version 
number, etc. This user— supplied data would normally be included 
as part of the data set when the content of the data set is 
defined to IPAD in accordance with section 5. 1.4. 3 and section 
6 . 0 . 


5-2-2-1 User Query 

It should be possible for the users to access data sets 
entering the information bank as a vrtiole or ty entering a 
specified data area- The latter should be considered the normal 
user access technique. If several data sets are identified by the 
user query, it will be the user's responsibility to make the final 
decision as to the data sets selected for further use. IPAD 
should support user queries such as the following: 

List headers for all existing sets for a specific data set 
name . 

List content of a data set by specifying data set name and 
specific header data. 

Compare contents of two or more data sets ty specifying data 
set name and specific header data. 

Create new data set (s) from existing data set ( s) by 
specifying data set name(s) , specific header data and 
parameters for data transformation or data ref ormatting - 
(See CR 2985, sec. 5.3.19.) 
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5. 2. 2. 2 


Coanput-er ProQrain Query 


It should be possible to link computer progr^s to data sets 
in specific data areas by defining the linkage and by specifying 
header data for input data sets and resiiltant output data sets at 
the time of program execution. The IPAD system shall have 
provisions to ensure that ambiguities cannot occur viien data sets 
are accessed by computer programs, i.e., it is the IPAD system's 
responsibility to deliver the proper data set(s) to the requesting 
program. 


5.2.3 DATA ACCESS CONTROL 

Access to data set headers and data values shall be subject 
to controls over user access and computer program access. 


5.2.3. 1 User Access 

User query of header data shall be subject to security 
classification of the data set. This means that with the proper 
seciirity clearance and proven need to know, a user may read any 
data set header . 

User access of data values of classified data sets shall be 
subject to the same restrictions applied to header data. In 
addition, access to xmclassified data values by a person other 
thain the owner for the purpose of reading (and perhaps making a 
copy) shall be subject to control. The purpose of this additional 
control is to limit to certain designated persons access to data 
which is preliminary in nature, difficult to interpret, etc. 


5. 2. 3. 2 Computer Program Access 

Computer program access to a data set, including its header, 
shall be siibject to the same control as a \iser access based on the 
person executing the computer program. In addition, computer 
program qfuery may be subject to schedule limitations. (See 
section 5.3.4.) 


5-3 ESVTA GENERATION 

The capability to plan and define a computer process such as 
the reference design process described in CR 29 81 and the required 
data interfaces such as the data model described in section 4.0 
shall be supported by IPAD- 


5.3.1 PROCESS MODEL 
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It is required that a general activity modeling capability for work 
integration be provided within IPAD that will support a structured definition 
of a work process consisting of the following principal elemsnts (these elemsnts 
will be described in reverse order) : 

PROCESS 

T.FVFTr. 

ACTIVITY 

JOB 


5. 3. 1.1 Job 


A job (see sec. 7.0) is defined to be any canputer program, group of inter- 
faced CCTiputer programs, or system function \dien any of these is executed on a 
ccxiputer as a single unit of work. A job may be sutmitted for batch processing 
or interactive processing where interaction between the job and the user is 
required during execution. 


5. 3. 1.2 Activity 

An activity is defined to be one job or a set of related jobs. An activity 
consisting of more than one job is usually grouped by managers of the design 
process for the putpose of efficiency, control and convenience. 


5 . 3 . 1 . 3 Level 


A level is defined to be one activity or a set of related activities. A 
level consisting of more than one activity is usually grouped by management 
for the purpose of establishing a predicted confidence level which may be used 
for risk evaluation. Levels are most significant as nanagement tools in the 
early stages of a process, i.e., conceptual design and preliminary design. 


5. 4. 1.4 Process 


A process is defined to be one level or a set of levels. A process con- 
sisting of more than one level is usually related to the phases required to 
develop a complete teclmical definition of a product, i.e., conceptual, pre- 
liminary, and detail design. A process requires that formal data interfaces 
for all related jobs be established and defined to IPAD. 
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5.3.2 DATA MODEL 


The IPAD system must provide the capability to identify data 
flow paths within ajiy arbitrary process defined to IPAD. A 
general data modeling capability of the type described in section 
4-0 is required. The resultant data flow will normally be under 
direct control of IPAD. Also, jobs within a defined process (see 
sec. 5. 3. 1.1) , which are executed on a satellite conputer (a 
remote system) must be recognized and suppoirbed by the IPAD 
system . 

All data will be transferred in data sets as follows: 

a) Transfer from a job to the information bank. 

b) Transfer from the information bank to a job 

c) Transfer from one job to another 

d) Any combination of a, b, and c 

e) Sent from the information bank to a satellite computer 
(remote system) in the IPAD communication network (see 
sec. 3.4) 

f) Received in the information bank from a satellite 
computer (remote system) 

Modes e) and f) require that the data be in a national 
standard format or IPAD standard format that can be interpreted by 
the receiving system. (See section 5.4.3.) 

Figure 66 represents typical planning for data flow within a 
defined process. The concept of data set types will promote 
packaging data into convenient sets for such things as review of 
interim results at a terminal, data used by a known downstream 
activity, etc . 
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Figure 66.— Data Flow Planning— Process Networks 




5.3.3 CONTROL MODEL 


The IPAD system must support the capability to control the 
progress of design projects. It is required that a general 
modeling capability for project planning be provided within IPAD 
that will recognize the following principle elements (these 
elements will be described in reverse order) : 

PROJECT 

TASK 


SUBTASK 


5.3.3. 1 Subtask. 


A subtask is defined to be the sequence of work accCHiplished 
by one individual which is a meaningful step in a project plan. A 
subtask may be recognized by IPAD as a scheduled event. A subtask 


may include one or more jobs . 


5. 3. 3. 2 Task 

A task is defined to be the 
by a group (discipline) which is 
A task may be recognized by IPAD 
include one or more siibtasks- 


sequence of subtaste accomplished 
a milestone in the project plan, 
as a scheduled event and may 


5. 3. 3. 3 Project 

A project is defined to be the sequence of tasks that are 
associated for the purpose of reporting. A project is usually 
accomplished by all disciplines required to produce the technical 

definition of a product. A project may incliade one or more tasks, 

however, within IPAD the size of a project will not be limited and 

may be only one subtask. Two types of projects may be defined. 

The first type will have formal schedule control and is the normal 
mode of operation. The second type will be informal and will not 
have schedule control. This mode is used for work not defined in 
a formal process such as computer program development, research, 
etc. 


5.3.4 SCHEDULE 

It is required that schedule planning for a project be 
supported by IPAD. It is envisioned that tasks will be scheduled 
by design project management and that subtasks will be scheduled 
by group supervision. Job execution will be scheduled by the 
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person doing the work and will not have formal identification in 
the project schedule. The capability will be provided to limit 
job execution based on the subtask schedule; however, in some 
cases it may be desirable to allow a subtask to begin prior to the 
subtask schedtiled date. 


5.3. 4.1 Critical Paths 

IPAD must support identification of critical paths for a 
project based on both task and subtask dependencies - 


5. 3. 4. 2 Schedule Reports 

IPAD must support identification of schedule problems. 
Lookahead capaLbility must be provided. This should identify such 
items as tasks due for conpletion in the next six months and 
subtasks due for couple tion in the next month. Provisions must be 
incorporated to notify responsible persons of potential schedule 
delays- This should be acconplished by monitoring data set 
occurrences in the information bank for projects under formal 
schedule control- Ihe notification shoxild list sub tasks for which 
approved input data sets are not available one week before the 
scheduled start date of a dependent siibtask. 


5.3.5 CCMPUTING RESOURCES 

It is required that computer resource planning and control be 
supported by IPAD. 


5.3.5. 1 Computing Resource Planning 

A computing resources budget will be established for each 
subtask of a project. The subtask will be related to the 
appropriate program item numer (PIN) established by the work 
breakdown structure (WBS) . (See sec. 4-0 of CR 298 3.) 


5. 3. 5-2 Computing Resource Report and Control 

A computing resource report is required which compares 
resources used to budgeted resoixrces. This report ;^ould identify 
subtasks, and accounting should be collected for each program item 
number (PIN) - The IPAD systan should only monitor resources and 
give alarms when unplanned resources are used. The user will be 
responsible for the resources consumed by each job and will 
establish appropriate time and/or resources limits- In cases 
where limits are exceeded, the system should suspend the subtask 
atnd hold for review by the user. Under control of the user, it 
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should be possible to restart any subtask at the exact point in 
the computation where the sxibtask was suspended- 


5 -3. 5. 3 Computing- System Performance, Monitoring and Control 

It shall be possible to moni-tor performance of the computing 
system during the prime interactive computing hoxirs , i.e., 9:30 
a.m. to 4:30 p.m. This moni-boring shall be based on parameters 
that identify the current use of resources. Response time based 
on tests of a standard interactive job and a set of test inquiries 
should be measured on a sui -table frequency to establish a control 
level of response performance. (See resource model, section 4.4.) 
If the response control level is less than a minimum standard for 
the tests, it shall be possible to make adjustment -to improve 
response time. (See section 4.3 of CR 2985 for specific response 
time requirements.) 


5.3.6 IPAD WORKING ENVIRONMENT 

The IPAD system must provide the capability to execute an 
arbitrary number of processes and coirre spending data models 
defined in accordance wi-th section 5.3.1 and 5-3.2 and control the 
execution of each process by an arbitrary number of projects 
defined in accordance with section 5.3.3. 

The primary IPAD working environment shall be interactive; 
however, IPAD shall also support batch processing. It is intended 
that the IPAD system recognize each iiser, the user* s computing 
jobs, and the user's data sets during the entire time of an active 
project under formal schedule control. There shall be no limit to 
-the number of active projects, and the IPAD system design will 
provide for an adequate number of host computers and storage 
devices operated in a distributed computing network. (See sec. 
5.4.) Figure 67 illustrates the working environment for one 
project execu-ted under IPAD control. 

Since the primary mode of operation is interacti-ve , it is 
anticipated that users will be required to work for long periods 
of time at -the terminal. IPAD shall ha-ve the following or 
equivalent provisions: 

The users should be able to suspend execution of a subtask 
for periods ranging from minutes to days. It ^ould be 
possible to restart the s-ubtask at the exact point in the 
con 5 >utation where the siibtask was , suspended . 
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Figure 67.— IPAD Working Environment 







The user should be able to switch frcxn interactive to batch 
processing when long confutations are under way. In this 
case the system should suspend the subtask after the job or a 
series of jobs have executed. It shall also be possible to 
restart the subtask at the exact point in the computation 
where the subtask was suspended. 

Provisions to monitor siibtask statiis are required to aid the 
user during interactive and batch processing and after sixspension 
of a subtask for any reason. 

The use of optimization techniques imposes special 
requirements. The user will specify the computational flow, i.e, 
the execution sequence of the modiiLes that will provide the 
optimizer with the required information. Once the program 
execution has begtm, the optimization driver will ccntrol the 
solution and the user will want to have intermediate results 
reported. These may cause the user to interrupt the solution, 
modify some of the initial information, and restart the 
optimization process. The user should be able to specify whether 
IPAD “should" or "should not" maintain copies of interim results. 
Optimization techniques are discussed in detail in section 5.0 of 
reference 6, Volume II. 

An analysis of the decision control specified in section 6.0 
of CR 2981 and the topical questions in appendix A identified the 
need for three basic decision modes: 1) computer (C) , 2) 
combination ccmputer and user (C/U) , 5uid 3) iiser (D) . Decision 
modes 1) and 2) can be characterized as programmable and decision 
mode 3) as norrorograramable. The programnable decision can usually 
be fully automated but may optionally be operated in an 
interactive computer-supported mode . The nonprogramnable 
decisions are judgemental and may be interactive conputer- 
supported or absolute-control-specified by the user. Figure 68 
depicts some characteristics of typical decision modes. 


5.3.7 RECORDS OF DATA OCCURRENCES 

It is required that records identifying data occurrences be 
provided within IPAD. It is intended that the IPAD system provide 
automatic bookkeeping capable of fully auditing all occurrences of 
data within the infoxrmation bank which have been generated by jobs 
executed under formal project control. These records will permit 
tracing the process that generated any output data set. These 
records should include the following as a minimum. 
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COMPUTED TESTS QUERIES (OPTIONAL JUDGEMENTAL COMPUTER JUDGEMENTAL USER 

BASED ON: COMPUTER OR USER) SUPPORTED QUERIES DECISIONS 

• CALCULATED •DEFINED •INTERACTIVE •SUSPEND 

VALUES PROCEDURES PROCEDURES SUBTASK 


•VALUES FROM • DEFINED DATA • INTERACTIVE DATA • PURGE SUBTASK 

INFORMATION MANIPULATION MANIPULATION DATA AREA 

BANK 

• COMPARISONS ‘COMPARISONS ‘TOTAL 

‘ CROSS PLOTTING ‘ CROSS PLOTTING ‘ SELECTED DATA SETS 

‘SORTING ‘SORTING 


• DEFINED DATA • INTERACTIVE DATA • PROCEED 

GATHERING GATHERING 


‘ SELECT DATASETS 

‘ SELECT DATA 
ELEMENTS 


‘ SELECT DATASETS 

‘SELECT DATA 
ELEMENTS 

‘ ACCESS REMOTE 
SYSTEMS 


‘ REPETE EXECUTION 
WITH NEW OR REVISED 
USER SUPPLIED DATA 

‘ SIGN OFF 
RESULTS 


Figure 68.— Characteristics— Typical Decision Modes 






5.3.7. 1 Data Set Originatiion Lcxt 


All data occruxrences shaill be identified at the time they are 
generated. These records shcaald include the following 
information: 

Date and time of origination 

User ID (owner) 

Data set ID: 

Data Set Name 

Project 

Task 

Sxibtask 

Pr oce ss 

Level 

Activity 

Job 

PIN 

Classification code 
System-assigned unique qualifier 


5.3 -7.2 Data Set Access Log 

All read accesses of data set occurrences generated under 
formal project control shall be recorded. These records should 
include 1) date and time of access and 2) user ID. 


5. 3. 7. 3 Data Set Modification Log 

a) Each write access shall produce a new occurrence of the 
data set and shall be recorded as a version when 
generated under formal project control- The records 
should include : 

Date and time of modification 

User ID 

Modification ID: 

Project 

Task 

Subtask 

Process 

Level 

Activity 
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Job 

PIN 

Classification code 

System-assigned unique version of the data set cjualifier 

b) All extend accesses shall produce an append^ version of 
the data set and shall be recorded as a version when 
generated under formal project control. Ihe records 
should include : 

Date and time of extension 

User ID 

Modif ication ID : 

Project 

Task 

Subtask 

Process 

Level 

Activity 

Job 

PIN 

Classification code 

System-assigned unique version of the data set qualifier 


5. 3. 7. 4 Notification of Data Set Changes 

The system must be able to notify affected users of data set 
modifications. These notifications shall be issued as both on-line 
messages and off-line batch reports mailed to the user. Data set 
change notifications shall be issued to all users identified on 
the access and modification logs. (See CR 2985, sec. 4.7.) 


5. 3-7. 5 Data Set Purge Control 

Special permission shall be required to purge any data set 
that has a dependent data set while these data sets axe xmder 
formal project control- When such a purge is required, there 
should be sever ad. levels of removing data with possiible recovery 
before final purging. In addition, a retention classification 
such as permanent, program life, project life, time (years, 
months, or days) shaLLl be provided. Project life should be the 
default rating and the system shall have provisions to selectively 
purge data set occurrences determined by retention classification 
to be no longer required. 
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5 . 4 DATA COMMUNICATIONS 


The feasibility study IPAD system architectiire (ref. 1, 
volxime IV) was conceived ais a host system with teleprocessing 
facilities to support interactive user communications with the 
IPAD system, information bank, and libraries. The trend in the 
engineering design environment is to move away from a centralized 
host which supports all activities to distributed remote 
facilities. These reinote facilities may consist of processors 
with computational and data storage capabilities connected to each 
other by communication links- Some or all of the processors may 
be: 1) specialized, 2) under the administrative control of a 
particular using organization, and 3) physically located with the 
using organization. 


5-4-1 SCOPE OF IPAD DATA COMMUNICATIONS 

IPAD shall permit access to central design data from remote 
sites and systems. The remote systems may or may not have remote 
IPAD system capabilities- Direct communications between remote 
systems shall also be supported- Data produced at remote IPAD 
sites shall have integrity equivalent to data produced on the host 
IPAD- Data produced on non-IPAD remote systems shall be received 
into any IPAD system- Such data shall have appropriate safeguards 
and controls while in the custody of IPAD. 


5.4.2 REMOTE SYSTEMS 

Remote systems communicating with the host system shall be 
permitted to operate in any of the following modes : 

Timesharing 

Remote job entry 

Message/file transfer 

Remote systems shall include intelligent systems tailored for 
specific design functions which may or may not have remote IPAD 
capability. The IPAD man-machine interface on a rertote IPAD 
system must not differ from that for the IPAD host interface 
unless required for specieil functions. 


5-4-3 STANDZ^RDS 

Standards should be used for all IPAD communications- The 
following are basic guidelines. 
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5. 4. 3-1 Existing Standards 


Existing standards should be selected, v^ere feasible, for 
IPAD to facilitate coinniunication between confuting systems and 
between aerospace companies. The standards identified by the 
National Bureau of Standards for the Air Force ICAM development 
{see reference 6) , should be reviewed with the goal to make 
cominunications conpatible between IPAD and ICAM. 


5 . 4 . 3 - 2 IPAD Standard Gecametry Format 

If geometric data are to flow freely within and among the 
comp>anies of the aerospace industry, a standard format for 
geometry data is needed- This format should express the basic 
ways of creating and storing a geometry description of aerospace 
vehicles and their component parts- The standard format would 
provide a reference point for the design of fut\rre geometry 
processors, thus reducing duplication of geometry programs and 
minimizing data translation. 

The IPAD standard should not limit the user's geometry 
capabilities- The standard is simply the data that IPAD can 
recognize as geometry . The user may have other geometry, 
formatted for the convenience of special-purpose geometry 
programs, that will be handled simply as data by IPAD or will be 
translated into the IPAD standard geometry format. 

The American Nationeil Standards Institute Y14 . 26 subcommittee 
(ref. 5) has proposed a standard for the digital representation of 
physical object shapes, based on associative geometry. In an 
associative system, an element (e-g., a surface) is defined by 
reference to other elements (e.g., curves) . Only the lowest-order 
elements — points — are defined numerically. The Y14 .26 element 
types include points, curves, surfaces, and volumes - 

Such a standard is considered adeqiiate for the communi cation 
of geometry, which is to say that physical shapes can, in general, 
be translated into associative formats. Y14.26, however, is not 
intended as a written language to support geometry generation . 
Also, its associative structvure is less efficient to evaluate than 
geometry based on explicit coefficients- Therefore, the IPAD 
geometry format should extend the Y14-26 proposal by including 
additional ways to generate elements and by allowing a 
(nonassociative) coefficient format where it serves the user. 

(All elements that can be expressed according to the Y14-26 
proposal should be expressible in the IPAD format.) 

The IPAD extensions to the Y14.26 proposal should adhere to 
the following gSroundrules; 

Be restricted to bounded geometry in parametric form 
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Allow new element types and geometry techniques to be 

accommodated as they are developed 

Operate in 2-D or 3-D according to the needs of the user 

Include a hierarchical structure for relating data such as 

assemblies, subassemblies, components, subcomponents, levels, 

groups, cells, strings, arrays, etc. 

The specific IPAD format should be developed in consultation 
with all members of the IPAD conmunity- The following offers a 
starting point for this developnient . 

Geometry elements should be stored in the information bank in 
either associative or coefficient subformat (associative for easy 
modification during development of geometry, coefficient to 
optimize evaluation of finalized elements) . Translation from 
associative to coefficient and back to associative subformat 
should not degrade the accuracy of the geometry definition. 

Under either subformat, each named element should store a 
header containing the name, element type, coordinate system name, 
optional title array, and the number of composite elements. (As 
an example of a composite element, a major airplane surface such 
as a wing might be composed of flap, leading edge, root, wing box, 
and tip surfaces.) 

Under the IPAD associative subformat, vhich should be an 
extension of the Y14.26 proposal, each element should also store, 
in appropriate representation, the function and parameter list of 
the written format that created the element. 

Under the IPAD coefficient subformat, the data after the 
header are the following: 

For points , 

X y z 

For polygonal functions , 

t 1 2 n Xi yi 

where "t" is an integer code indicating that a polygonal 
curve follows, ^ < x < 2 , "n" is the nrmber of 
coordinate values expressing the curve, and "Xi y^ ..." 
are the coordinates of the 2-D or 3-D points describing 
the cixrve . 

For polynomial functions, 

ti ^ c c c ...c 
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where f (x) = c x +c x +... + C 

Also polynomial functions of several variables 
will be defined in a similar' manner, e.g., 

where f (x,y) = c x y 

For conic functions 

t j 2 abcdef, 

v^ere f (x) = ax + b + c dx^ + ex + f . 


5-5 DATA MAINTENANCE 

Data maintenance is concerned with the day-to-day upkeep of 
the IPAD information bank as it is stored on various types of 
storage devices. These devices fall into three broad categories: 
on-line/direct access, on-line/archival , and of f-line/archival. 
Maintenance of off-line storage is not an IPAD system concern, hut 
is dealt with by procedures and manual methods. Since on-line 
storage devices are subject to mechanical and electronic failures, 
the following or equivalent maintenance features must be provided. 


5.5.1 RESPONSIBIUETY FOR DATA MAINTENANCE 

Responsibility for data maintenance of the entire IPAD 
information bank lies with the information bank administrator (s) . 
This includes data in all data areas and all aspects of online 
data maintenance. 


5.5.2 DATA MAINTENANCE FUNCTIONS 

The following functions should be a part of the IPAD system 
and available to the administrator (s) : 

Dump to offline storage of: 

One or more specified data sets 

One or more data areas 

All data sets which have been altered since a specified 
time and date 

Entire information bank 

Restore from offline storage of any previous dump with: 
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Elimination of current on-line version 


Restoration of only those not currently on-line 

Restoration of specifically designated data sets and/or 
data areas 

Catalog of entire contents, one or more areas, or one or more 
data sets 

Diagnostic program to check catalogues and data sets for 
abnormal it ies 


6.0 INF ORMATl ON MANAGEMENT 


This section descriiies the general principles of how data 
should be organized in detail to support the information 
processing requirements for the engineering design process. It is 
required that I PAD support an orderly growth of data definitions 
within an IPAD information bank. In addition, IPAD shall svpport 
an orderly growth of occurrences of data correspcsiding to the 
definitions. 


6.1 LOGICAL INFORMATION MODEL 

The IPAD information bank shall have provisions to relate 
information in a specifically defined sense to the IPAD system. 

The following or an equivalent hierarchial information modeling 
capability shall be provided to support information definition 
within the IPAD information bank. (These will be described in 
reverse order.) The need to define data and relaticnships within 
data is expressed in many publications. References 4, 11, 12, 13, 
14, 15, and 16 are some examples. 

Data Format 

Data Relationship 
Data Element 


6.1.1 DATA ELEMENT 

A data element is the smallest definable item in the 
information bank. A data element definition consists of the 
meaning (engineering, mathematical, etc.) of the entity and some 
description of its nature, if appropriate. Some examples are: 

Mach No. = The ratio of trainslational velocity in a fluid 

to the accoustic velocity in the same flxiid 

Load Vector - A one-dimensional array of numbers 

representing the loads applied to a structure 
at a specified set of points 

Airplane 

Model No. = An identifier for a specific airplane model 

Actual occtirrences of data associated with a data element exist 
only as members of data sets (sec. 5.1.1) . Data elements may be 
single valued (in the sense of scalars) or mult iple -valued (in the 
sense of vectors and matrices) . 
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6.1.2 DATA RELATIONSHIP 


A data relationship is a logical grouping of data elements 
and data relationships. Uie purpose of a data relationship is to 
logically associate a set of data elements (the inclusion of a 
data relationship in ainother data relationship is the way of 
expressing nested relationships) . Some examples of data 
relationships arer 

Wing Planform = aspect ratio, taper ratio, sweep angle, 

area basic trapezoid, span, wing model 
ntunber, configuration model number. 

Loads Matrix = repeated load vectors with an associated 

load set number. 

Data relationships are the medium in which users express how 
they associate and use data. A data relationship will be used to 
describe all the logical relationships which exist in the 
information bank. Some relationships may be a permanent part of 
the information bank and others may be transient, such as queries 
or reports. In this manner, the logical description of data input 
to a program will be one or more relationships and so will a 
Boolean qpiery request. 

If multiple data relationship occurrences appear in the 
information bank, the values of a subset of the data elements 
will, in general, permit rtnique identification among all 
occurrences of that data relationship. This subset may range from 
one element to all elements in the relationship. It should be 
possible to reference any or all items in a relationship in the 
manner of a query. 

A data element may be a member of etny nvmber of data 
relationships. A data relationship may be a member of any number 
of data relationships, but cannot be a member of itself. 


6.1.3 DATA FORMAT 

A data format defines the structure of one or more data 
relationships and/or data elements which are grouped together 
because: 

They form an input set to some program 
They form an output set of some program 
They are easier to handle as a single item 
They are required for a report 
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Processing requirements make it advisable 

Any other reason relating to user or computer needs 

A data format should have physical storage structure 
associated with it, sample data format definition information 
includes: 

The logical contents: 

Data elements names 
Data relationship names 
The structure : 

Sequential (order of items, no. of files, etc.) 
Nonsequential (access method identifier) 

The format : 

Each data element 
Each data relationship 

Units of measure (same as data element unless conversion 
is required, see sec. 6.2.2) 

File type (s) 

Data managenent program (s) identifier 


6.2 DATA ELEMENT DEFINITION 

The definitions of data aire expressed as data element 
definitions. The total set of data element definitions existing 
in the IPAD information bank at any one time fully denotes all the 
data that can be accessed as information by the ^stem. These 
definitions contain information about its me£ming, physical 
significance, or mathematical nature. 


6-2.1 RESPONSIBILITY FOR DATA ELEMENT DEFINITION 

The responsibility for data element definition is separate 
from the responsibility for generating or maintaining actual data 
element values. All definitions residing in a common, data element 
dictionary must be xinique and \inambiguous . In principle there is 
a dictionary for data elements associated with each data area in 
the information bank. Since any given data element may be a 
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member of many data areas, a dictionary common for areas may be 
necessary. 


6.2.2 ESTABLISHMENT OF DATA ELEMENT DEFINITION 

Data element definitions are estciblished in tbe dictionary 
consistent with its data area membership. 

Establishment of data element definitions can be controlled 
by permission codes (see C3i 2985, sec. 4.8.1) and by access to the 
appropriate dictionary. Uie act of establishing a given data 
element definition involves the siibmission of all the required 
definition information and any desired portion of the optional 
information, as described below. 

Required information includes: 

Data element name — must be unique within the designated 
dictionary 

Data elements synonym (s) — must be unique within the 
designated dictionary 

Textual definition 

Keyword list for data element definition 

lype of data primitive, e.g., scalar, vector, table, 
etc., (see 6.2.4) 

Units (meters, seconds, etc.) 

Optional information: 

Display format 
Default value 
Mathematical definition 
Restrictions on usage 


6.2.3 USES OF DATA ELEMENT DEFINITION 

The primary use for the data element -definitions is to 
establish a systematic ba^is for communication. In this case the 
communication needs involve three parties; engineering users, 
technical computer programs, and the information bank. Since two 
of these are computerized, it will place some restrictions on how 
the definitions will be handled. 
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A primary cxjnflict between himan usage of definitions and 
computer usage is the human's ability to "understand" the context 
in which certain terms are used withoxit having to be explicitly 
told each time. This permits (or perhaps caxises) people to use a 
Icinguage that contains ambiguities and lacks mathematical 
preciseness. The computer will always respond out of the context 
it is in, i.e., out of the dictionary it is looking at; thereforev 
the elements of each dictionary must be xinique. 

Among the three parties mentioned cibove, there are three 
basic communication paths: 

Human to/frora information bank 

Human to/from jobs 

Jobs to/from information bank 

If a request for information results in an ambiguous 
response, the recipient must have some means of resolving the 
ambiguity or communication fad_ls. For example, a person could ask 
to see the definition of "wing area" and receive five items all 
defined as "wing area." He could then examine the definitions and 
decide that one (or none) of them is what he wants. Since this 
decision process is not, in general, describable as a mathematical 
algorithm, this kind of ccHiutnmcia tion would fail if the requestor 
were a technical program. This leads us to the conclusion that 
ambiguity is sometimes permissible and even desirable when humans 
are in the loop, but not vhen both parties are conp uteri zed. 

There are two basic uses of data definitions: 

A data element name is knovm and most be identified 
uniquely among all other data elements. 

Some knowledge about the definition of a data element is 
known and it is desired to establish the name of the 
associated data element. 

The first of these is required by computer programs; the 
second is typical of a searching activity by people unfamiliar 
with the total contents of the dictionary. Ihe first may also be 
done by people (say, by a person who wants to be sure of a 
definition of a known element) , but the second may not done by 
technical programs apart from human interaction. Thus the data 
element definitions must serve these fxinctions. 


6.2.4 TYPES OF DATA EhEMENT DEFINITION EXPECTED 

The IPAD information bank must accommodate all data element 
types that can be produced by any language processor in common 
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use. Type refers to the nature or chair acterxs tics of the 
elements. Below are a few examples of such types, hereafter 
referred to as data primitives. 


1) 

Label or title 

Arbitrary set of characters used 
by engineer to identify data 

2) 

Text 

Arbitrary set of characters 
used to describe any data 

3) 

Singl e-valued 
quantity (scalar) 

Single number representing 
a calculated or assigned value 
of a mathematically defined item 

4) 

Vector or matrix 

An array of numbers representing 
a set of values vhich have a 
precise mathematical relationship 

5) 

List or table 

An array of nimbers representing 
a set of values resulting frcxn 
observation or data collection of 
some type 


While these examples do not exhaiist the possibilities, they 
illustrate one of the distinct differences to be found in the 
information bank. 'The major difference between 4) and 5) is the 
presence of a mathematical basis for the relationship within the 
array, and the possibility of complex calculations to derive the 
array. The items in 5) tend to be observed or tabulated data, and 
operations like updating tend to be simple replacement with 
another tabulated number. 


6.3 DATA RELATIONSHIP DEFINITIOSJ 

Data relationships are described through data relationship 
definitions. A data relationship is a named collection of data 
elements and/or data relationships. Each data element or data 
relationship contained in a data relationship is referred to as a 
member of that relationship. The only restriction is that a 
relationship may not be designated as a member of itself. As with 
data elements, data relationships contain no information about the 
physical form in which the data is stored, but only logical 
associations between elements and relationships . However, scane 
kinds of relationships imply a physical form which would be a 
"natural" way to arrange the data values. 


6.3.1 RESPONSIBILITY FOR DATA RELATIONSHIPS 

Since data relationships are established throuch data 
relationship definitions, data relationship dictionaries will be 
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established in a manner similar to tlie data element dictionaries, 
i.e., associated with the appropriate data areas. 

Responsibilities for the various data relationship 
dictionaries are exactly parallel with the data element 
diet ionari es - 


6.3.2 ESTABLISHMENT OF DATA RELATIONSHIPS 

Data relationships are established through the definition of 
a data relationship in a data area dictionary. The definition of 
a particular data relationship can be controlled ty : 

Permission codes for data relationship definition 

Access to the appropriate dictionary for the purpose of 

extending it 

The act of establishing a data relationship definition 
requires the following information to be specified: 

a) A symbolic representation of the data relationship 
such as; 

data relationship = R = r (r ) where K ^ j 

or 

R = r (R ) where K ^ i 

v^ere r = data record = an enumera tlon of data 

elements and/or data records 

i = 1, m; m being the nxmber of data relationships 

j = 1, L; L being the total number of data records 

K = any niimber in the set 1, m or 1, L 
N = number of occurrences for each occurrence of r 

b) Specification of which data element in the relationship 
is primary and vdiich are secondary 

Note that a relationship name is only a label for a 
collection of data elements and relationships and thus is a kind 
of pointer to other names. There is no purpose in having a 
relationship defined to have jiist one member. 


6.3.3 USES OF DATA RELATIONSHIPS 

The primary use of data relationships is to help organize the 
data for access by the users. Some data is always directly 
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accessed by the users and some data is accessed only through other 
data. In a personnel information bank, a person's organization is 
generally accessed aifter his naite or con^any identification has 
been used to locate the additional information. In a similar way, 
the performance figures for an airplane can be accessed through 
model n\mber, i.e., by configuration identification. In both of 
these cases, the access path may be reversed (e.g., what airplane 
model ntunbers have range between 2000 and 3000 miles and payloads 
between 175 and 200 passengers) . 


6.3.4 TYPES OF DATA RELATIONSHIPS EXPECTED 

Within the IPAD information bank there exists a small number 
of types of relationships, but because of the nested definition of 
a data relationship, there may be an arbitarily large selection of 
relationships available. The following are examples of two ccmmon 
types of relationships and scxne of their characteristics. 

Nested lists (ordered or unordered) : 

Number of elements per list 
Number of levels of nesting 

Type of elements as a fvmction of each nested level 
Searching logic required 
Number of keys 

Nested (intersecting) rings (ordered or unordered) : 

Number of elements in a ring 
Number of intersections 
Types of elements in the ring 
Searching logic required 
Number of keys 


6.4 DATA FORMAT DEFINITIGNS 

Data formats are required to describe the storage and 
retrieval structxire of each specific occurrence of data. The data 
elements and relationships have to do with the meaning of data and 
how it is used in a logical sense. The data formats have to do 
with the practicalities of handling data for use by people and 
computer programs . Prior to the generalization of data 
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management, definitions and format were both dictated by the 
computer programs. Relationships were seldom formally defined aind 
existed implicitly in the program and in the user's mind. Now 
that the three concepts are being treated separately, there is a 
need to formalize data format apart from the defining conqouter 
program . 


6.4.1 RESPONSIBILITY FOR DATA FORMATS 

Data formats are required for defined and undefined data 

sets. 


6. 4. 1.1 Data Formats for Defined Data Sets 


A data format for a defined data set involves cne or more 
data elements and/or data relationships. Consequently, the 
responsibility for data format definition lies with the 
corresponding element and relationship dictionaries . 

Because data formats have associated occurrences of data 
sets, there is the additional responsibility for the occurrences 
apart from the definition. Since all occurrences of data begin in 
a single subtask data area, the storage data area dictionary must 
be known to obtain the definition. 


6 . 4 . 1 . 2 Data Formats for Undefined Data Sets 


A data format for an undefined data set is considered a 
degenerate case for which the content data is not defined to IPAD. 
Data sets of this type will be related to the host operating 
system and in essence IPAD will only provide file management. {See 
section 5.0.) 


6.4.2 ESTABLISHMENT OF DATA FORMATS 

Data formats are established through a definition entered 
into a data format dictionary. Its data area meitbership is 
dependent upon the data area meiribership of its component elements 
and relationships. Establishment of new data format definitions 
can be controlled by: 

a) Permission codes for data format definition 

b) Access to the appropriate dictionary for the purpose of 
extending it 

The act of entering a data format requires infonnation such 
as the following to be supplied: 
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a) 


Fixed Structure — Data format name 


b) Variable Structure — Formal description of the storage 
and retrieval structure of the data in terms of the 
elements and/or relationships and the logical order 
within the data set (if order is of importance) 

c) Algorithmic descriptions of how elements can be stored 
and retrieved from the data set (may be more than one 
for each element) 

d) A table of permissible data elements and units of 
measure 


6.4.3 USES OF DATA FORMATS 

Data format definitions are used to interpret the contents of 
a defined data set, i.e., to know the storage structure of the 
data set. The fixed portion of the definition defines the logical 
content vdiile the variable portion defines the actual form of the 
data. A data set carries with it specifications of which options 
of the variable portion are in effect. Programs requesting data 
from a particular data set will specify its required options and 
expect any required transformations to be done if there is a 
mismatch. 


6.5 INFORMATION QUERY 

The requirements stated in this section apply to query at the 
data element level. This implies that the data elements and data 
relationships have been defined and their structure is specified 
in a data format for a defined data set- The requirements for 
data set header information specified in section 5.2.2 also apply 
to defined data sets- 


6.5.1 USER ACCESS TO DATA ELEMENTS 

It should be possible for the users to access data elements 
values within defined data sets by entering the information bank 
as a whole or by entering a specified data area. The latter 
should be considered the normal user access techniqxie. If several 
data elements are identified by the user query, it will be the 
user's responsibility to make the final decision as to which 
values are selected for further use. IPAD should s import user 
queries such as the following; 

List all values for a specified data element name 
Example: List DEn 
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List all aggregates of data values for a data relationship 
name 

Exanple; List DRn 

List an aggregate of data values based on a data relationship 
but qualified by values of data elements or values calculated 
from data elements. 

EScaniple: List DRn vdiere DEn EQ specified value 
or range of values 

List DRn where DEn^ - DEn EQ 
specified value or range of values 

6.5.2 CCMPUTER PROGRAM ACXTESS TO DATA ELEMENTS 

It should be possible to link computer programs to data 
elements and aggregates of elements based on data relationship in 
a specific data area by defining the linkage and by specifying 
header data for inpiit data sets and resultant output data sets at 
the time of program execution. (See section 5.2.2.) The IPAD 
system shall have provisicwis to ensure that ambiguities cannot 
occur when values for data elements are accessed by computer 
programs, i.e., it is the IPAD system's responsibility to deliver 
the proper values for data elements to the requesting program. 
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7.0 COMPUTER PROGRAM MANAGEMENT 


This section describes the general principles of how cori 5 >uter 
programs are to be organized to support the inf ormati on -processing 
requirements. These requirenents apply generally to both user 
programs and IPAD system programs, although there m^ be 
exceptions . 


7.1 COMPUTER PROGRAM LIBRARY ORGANIZATION 

An IPAD computer program library consists of user-supplied 
programs that use or create data identified in the IPAD 
information bank dictionaries. An IPAD computer program library 
has the following or equivalent structure. (These will be 
described in reverse order.) 

Job 

Operational module 
coding module 


7.1.1 CODING MODULE 

A coding module is the smallest collection of computer code 
that can be defined to IPAD. It may be as small as a single 
FORTRAN subroutine or as large as an overlay program. It has two 
key characteristics I 

a) It is handled as a unit by IPAD (but not 
necessarily executable as a unit) . 

b) The source code portion may be submitted to a 
single language processor - 

The first chciracteristic motivates one to define coding 
modules for maximum modularity unless the code is totally special 
purpose. The second is oriented to neatness. A coding module 
must have source code and may optionally have object code. 


7.1.2 OPERATIONAL MODULE 

An operational module is one or more coding modules that form 
an executable unit. The key characteristic of an operational 
module is that it is an executable collection of conputer code (a 
coding module is not necessarily executable) . A parallel property 
to the source code of coding modules is that the object code for 
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an operational module is submittable to an operating system 
loading processor. 

A large computer program composed of highly interdependent 
H-odules may well be inserted as a single coding module, which in 
turn is defined as a single operational module. A long-range goal 
is that operational modules will be made up of a nuirber of coding 
modules, some of vdiich are present in other operational modules as 
well. 


7.1.3 JOBS 

A job is an executable sequence of operational modules and/or 
other jobs that produces meaningful results for a user. A job is 
the only form of conputer code that the user actually executes. 

In general, a job consists of a number of operational modules 
connected with logical decisions (programmed or left to human 
interaction at execution time) \^ich determine the sequence of 
execution. The nested characteristic of jobs permits building new 
jobs on the basis of already defined jobs. In the siirplest case, 
a single coding module defined as a single operational module can 
be defined and executed as a job. Similar to the coding 
module/operational module relationship, the long-range goal for 
jobs is that they be composed of many operational modules, some of 
which are used in many jobs. 


7.1.4 DATA AREA MEMBERSHIP OF COMPUTER PROGRAMS 

Membership of a job in a given data area is mandatory when 
that job references a data format belonging to the data area- The 
execution of a job will always take place in a siibtask data area 
and all data generated will initially reside in that area. If the 
job modifies an existing data set, area membership of that data 
set must have already been established. 


7.2 CONTROL OF COMPUTER PROGRAMS 

Control of computer programs is as important as control of 
the data they generate. If a given data set is generated by a 
program, total control over that data is not possible without 
having control over the program that generated it. Therefore, the 
generated (output) data must also contain the input data and the 
identity of the program that produced it in order to be complete . 
IPAD must not permit deletion of a conputer program (version) 
having a dependent data set in the information bank - 
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^. 2 .^ RESPONSIEILIlTf FOR COMPUTER PROGRAMS 


The execution of an operational module as a part of a job 
always produces occurrences of data and affects the IPAD 
information bank. Since coding modules are normally not executed, 
the operational module becomes the focus for control of computer 
programs. 

Responsibility for operational modules is normally linked to 
their output data formats- Hie person or persons responsible for 
definition of the data formats referenced in a given operational 
module as output should also be responsible for the operational 
modules and their coding modules. 

Responsibility for a job definition involving one or more 
operational modules may lie with anyone authorized to construct 
jobs. Of course, the data area containing that job must be one of 
those listed in the data format definition of the output data for 
the job. 


7-2.2 COMPUTER PROGRAM CERTIFICATICHS 

In order to document the integrity of a given job execution, 
its component operational modules must be certifiable in some 
fashion. By "certifiable," it is meant that a judgment may be 
made about the txustworthiness of the computer code to perform its 
intended task. As an exanple, an operational module may have one 
of the following certifications : 

In checkout 

Research use only 

Staff use 

Airplane program/model use 

FAA certification use (legally certified) 

Since only a job is executed by a user, the certification of 
a job is the same as the "highest" certification operational 
module contained in the job. 


7.2.3 VERSION CONTROL 

Since mai^ changes may be made to a computer program, there 
must be a mechanism for automatically recording program versions - 
This applies to coding modules, operational modules, and jobs- 
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7.3 COMPUTER PROGRAM INSTALIATION INTO IPAD 

IPAD is required to support several inodes of 
program/data/information interfaces with the information bank. 

The primar-y purpose is to make provisions which allow simple 
installation of existing programs into IPAD. All programs 
installed in IPAD should have the fxiU benefits of the general 
data management feature described in section 5 . 0 , and it should be 
possible to utilize any or all of the information management 
features described in section 6.0. Four possible modes of 
installation are illustrated by figure 69 and are identified as; 

Mode 1 This concept implies that the contents of all input 
and output data sets are defined to IPAD and that 
all data management by IPAD is implicit. 

Mode 2 This concept implies that the contents of some 

input and output data sets are defined to IPAD and 
that both implicit and explicit I/O is performed by 
IPAD. 

Mode 3 Like mode 2 , this concept implies that the contents 
of some input and output data sets are defined to 
IPAD but are translated for ejq>licit I/O by IPAD. 

Mode 4 This concept implies that the contents of input and 
output data sets are not defined to IPAD and that 
all data management by IPAD is explicit. 

The use of the terms "iirplicit" and "explicit" I/O should be 
interpreted as follows; 

Implicit input/output action to and from a data set is 
totally under the direct control of IPAD. Note; Query is 
possible at the level of data elements. 

Explicit input/output action to and from a data set is tinder 
control of the user program. IPAD is responsible only for 
the data set as a unit. Queiry is possible at the level of 
data set and in general, IPAD is not capable of interpreting 
the content of any data set handled in this way. 
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Figure 69.— Computer Program Installation Into IPAD 






















8.0 


CONCLUSIONS 


Ciorrent conmercially available data management systems enable 
the inforaation systems designer to adequately define simple 
business-type data such as text, date, money, and numbers. Many 
of these data management systems provide multiple interfaces to 
the information system in the form of self contained query-type 
languages plus a data manipulation language that can be used with 
host languages such as FORTRAN or COBOL. It is concluded that the 
unique requirements for an engineering information hank are 
expressible as additions to these capabilities and that IPAD 
should provide features for general scientific data management at 
the set (or file) level, information management at the element 
level and management of user supplied ccjmputer program in the form 
of a library of modules that are readily available to a community 
of users. The element types in scientific data management must 
include all those in business systems plus cctnplex vector and 
matrix types, which may be very large yet still be considered a 
single data element . 

It is further concluded that the IPAD system management 
features should take the form of general tools that will allow any 
company to implement its version of the design process, computer 
program library, and information bank. Finally, it is concluded 
that each of the management features should be subdivided so that 
the degree of implementation chosen by a coirpany can be tailored 
to the needs of that company. For example, it should be possible 
to "switch off" such features as the records showing source of 
data sets or the project control features for schedtile control. 

In addition, it should be possible to operate in a file managenent 
mode where data sets are treated as files and the content 
(elements) of the files are not defined to IPAD. 
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APPENDIX A 


TYPICAi QUESTIONS 


This appendix contains a list of typical questions that users 
must answer relative to the control decisions identified in the 
reference design process described in section 6-0 of CR 2981. The 
decisions are identified by the same number and include project 1 
the subsonic transport (sec. 6.2) , gather information (sec. 6.5) 
and structural detail design (sec. 6.6.1) . 

Decision II-4. Design Mission OK? 

1. Will mission yield a competitive share of market? 

2. Have growth and off-design performance requirements 
been identified (e.g., growth range and payload, 
wind, temperature, airfield conditions, etc.)? 

Decision II— 8. Suitable Sales Potential? 

Will sales potential and return on investment justify 
development costs? 

Decision III-4. Type B Weights Available? 

Has block III— 17 (calculate weight, balance, 
loadability. Type B) been executed for the configuration 
being sized and, if so, is weight data valid? 

Decision 111-8. Loadability/OEW Criteria Met? 

1 . Is the calculated and allowable OEW within 
acceptable tolerance? 

2. Are the center -of-gravity excursions based on 
operational criteria within available 
aerodynamically calculated forward and aft center— 
of— gravity limits? 

3. Does the OEW center of gravity result in acceptable 
airplane balance? 

Decision III— 10. Design Criteria Met? 

Do deficiencies in meeting criteria exist (as determined 
by comparing calculated performance with criteria) ? 
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Decision 111-16, Flexibility Change Significant? 

Are calculated flexibility of structure and initial 
assuaed flexibility of structure within acceptable 
tolerance? 

Decision IH-19- Loadability/OEW Criteria Met? 

Question types are the same as decision lH-8. 

Decision III— 20. Do Flutter Analysis? 

Has block III— 22, Flutter Analysis, been executed for 
the configuration being sized or for an equivalent 
configuration and, if so, is flutter data valid? 

Decision IU-25. Configuration Acceptable? 

Will primary structure sizing resiilt in significant 
changes in the estimate of perfoinnance, noise, cost, and 
market suitability? 

Decision III— 26, Modify Configuration or Mission? 

If configuration is not acceptable (Decision III-25) , 
can the configuration be modified or is a modified 
mission required? 

Decision IV— 3. Geometry Change? 

1. Are the objectives for isobar patterns and span 
loading met? 

2. Are camber, twist, or thickness modifications 
required? 

Decision IV-6. Geometry Change? 

1 . Is stability deficient? 

2. Is control effectiveness below requirements? 

3. Are significant changes required in size of control 
surfaces? 

Decision IV-7. Stability and Control Acceptable? 

1. Are stability and control criteria met within 
acceptable tolerance? 

2. Are minor modifications of control surfaces size or 
rate of surface actuation required? 
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3. Should stability and control analysis be repeated? 

Decision IV— 8. Start Wind Tunnel Model? 

1. Does the aerodynamic analysis (ref. block IV-2) and 
Stability and Control Analysis (ref. block IV-4) 
show good results? 

2. Should design of a cruise shape wind tunnel model 
be initiated? 

Decision IV— 11- Entered at M? 

Have flight control system synthesis and analysis — 

elastic body modes (block rV-53) — been executed for this 

or a similar configuration and are the data valid? 

Decision IV-13. Fligfit Control System Criteria Met? 

1. Are flight control system criteria met within 
acceptable tolerance? 

2- Is a technical review required to determine action? 

Decision IV-16. Installed Ihrust on Specific Fiael Consumption 

Change Significant? 

1. Are the calculated installed thrust and specific 
fuel consumption within acceptable tolerance with 
the values assumed in levels II and III? 

2. Are changes in the configuration required? 

Decision IV— 19. Entered at M? 

1. Have all required level IV analyses been completed 
and are results satisfactory? 

2. Are manuf acturing reviews required? 

3. Are suirenaries of level IV activities completed? 

Decision IV— 22. Flexibility Change Significant? 

1. Is calculated flexibility of structure and the 
flexibility of structure assumed from level III 
within acceptable tolerance? 

2. Should static loads (block IV— 20) and structure 
sizing (block IV-21) analysis be repeated? 

Decision IV— 24. Structural Concepts Satisfactory? 


1. Can stxTictiiral cancept-s be changed to improve 
efficiency? 

2. Can structural concepts and arrangements be further 
optimized? 

3. Is redefinition of structural concepts required? 

Decision IV-26 . Panel Mass or Inertia Change Significant? 

1. Are effects of panel mass, center-of -gravity , and 
inertia changes within acceptable tolerance? 

2- Should the loads and structural analyses be 
repeated? 

Decision IV-27 . Loadability/OEW Criteria Met? 

1 . Is OEW within acceptable tolerance? 

2- Is center-of —gravity excursion within available 
aerodynamic c.g. limits? 

3. Is airplane balance satisfactory? 

Decision IV— 32- Flutter Criteria Met? 

1- Does flutter deficiency exist? 

2- Is any change in geometry, mass, or stiffness 
required? 

3. Should an active flutter suppression sytem be 
investigated? 

Decision IV-3. Geometry Change? 

1. Are modifications of the primary lifting surfaces 
and/or control surfaces required? 

2- Are new control surfaces required to achieve 
flutter clearance? 

Decision IV-34- Use Flutter Suppression System? 

1. What are benefits, risks, cost, complexity, and 
weight of flutter suppression system? 

2. Should flutter suppression system be incorporated? 

Decision IV— 36 - Change Stiffness? 
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1 . 


What Is weight increase for required increase in 
stiructural stiffnss? 


2. Should structural stiffness be incorporated to 
achieve flvttter clearance? 

Decision IV-39. Loadability/OEW Criteria Met? 

Question types are the same as decision IV— 27. 

Decision IV— 40. Entered H from J? 

Have dynamic load and ride quality analysis (block IV— 

42) been executed for this or similar configuration and 

are the data valid? 

Decision IV-44 . Negative Margins of Safety? 

Are dynamic loads critical for any structural element? 

Decision IV-47- Flexibility Change Significant? 

1. Are new calculated flexibility and the previous 
flexibility within acceptable tolerance? 

2. Should static loads (block IV-45) and structure 
sizing (block IV-4 6) analyses be repeated? 

Decision IV-49« Panel Mass or Inertia Change Significant? 

1. Are effects of panel mass, center-of -gravity, and 
inertia changes within acceptable tolerances? 

2. Should the loads and structural analyses be 
repeated? 

Decision IV— 50. Loadabilty/OEW Criteria Met? 

Question types are the same as decision IV-27. 

Decision IV-51. Do Piutter Analysis? 

Has flutter analysis (block IV-31) been executed for 

this or a similar configuration and is the data valid? 

Decision IV-54.. Do Dynamic Loads Analysis? 

1. Have significant changes in weight, flexibility, or 
flight control been identified and, if so, should 
dynamic loads analysis (block IV— 42) be repeated? 

2- Is final update of systems required? 
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Decision IV-57. Will Engine be Available for Product? 

Is engine availability schedule compatible with airframe 
development schedule? 

Decision IV-59. Configuration Acceptable? 

Have reviews indicated deficiencies in the 
conf i gur ation? 

Decision IV-61. Start Wind Tunnel Model? 

1. Does the completed level IV analysis show good 
results? 

2- Should design of a cruise shape wind tunnel model 
be initiated? 

3. Is technical review required to determine next 
action? 

Decision IV-62. Wind Tunnel Model Started? 

Was cruise shape wind tunnel model initiated by decision 
IV- 8? 

Decision IV-63. Modify Configuration or Mission? 

If the configuration is not acceptable (decision XV-59) 
can the configuration be modified or is a modified 
mission required? 

Decision V-1 . Wind Tunnel Model Changes Required? 

Does the cruise shape wind tunnel model design initiated 
in level IV require any modification? 

Decision V-7. Configuration Acceptable? 

1. Is cruise performance as predicted or within 
acceptable tolerance? 

2. Are longitudinal stability and control acceptable? 

3- Are lateral and directional stability and control 
acceptable? 

Decision V-1 4. Recycle? 

Do test results indicate additional testing or revision 
in design? 
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Decision V-15. Configuration Acceptable? 

1. Can the conf iguration meet the initicil design 
criteria? 

2* Are adequate growth capabilities identified to 
fully establish growth criteria affecting the 
selection of such critical factors as wing areas, 
high lift configuration, propulsion arrangements, 
and fuselage extensions or deletions to increase or 
decrease payload, etc-? 

Decision V-18. Sales Go-Ahead? 

Has a management conmitment been made to authorize sales 

of the product? 

Decision V-19- Firm Orders? 

Are there sufficient customer orders to initiate product 

go-ahead? 

Decision V-21. Product Go-Ahead? 

Do projected future sales and estimated retTxrn on 

investment justify development costs? 

Decision VIA-5. External Loads Available? 

1. Have the basic airplane loads been distributed to 
the structure? 

2 . Have the local maximum shears and moirents been 
determined for this structure for all load 
conditions, maneuver loads, gust loads, ground -air- 
ground loads, internal pressure loads torsion 
loads? 

Decision VIA-9- Structural Element Concept Developed? 

1. Has a design concept been developed for this 
structure that appears feasible and needs only 
sizing for completion? 

2. Is a typical cross-section (channel, zee, etc.) 
available? 

3. Is the frame concept a formed or built-up section? 

Decision VIA— 14. Structural Element Concept Ccmpatible? 
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Is the structural element concept compatible with the 
interfacing structure in strength, stiffness attachment, 
appearance, and is it within envelope boundaries 
{inner/outer contours and width) ? 

Decision VIA.— 15. New Structural Element Concept Required? 

Can the structural element concept be varied enough to 
be compatible with interfacing structure and carry its 
loads and fit the envelope, or must a new structural 
element concept be developd? 

Decision VIA-16. Revise Structural Element Concept? 


Will a different structural element concept carry the 
loads, fit the envelope, and still be compatible with 
the existing adjacent structure for strength, stiffness 
and attacJment? 


Decision VIA-18. Revise Adjacent Structural Concept? 

1. Can a revised adjacent structural concept carry its 
loads and be compatible in strength, stiffness, and 
attachment to its adjacent members? 

2. Are the cost, weight, appearance, and envelope of a 
revised adjacent structure acceptable? 


Decision VIA-20. System Interface Developed? 

1 . Are there systems interfaces? 

2. Are ^stem interfaces developed for location, 
function, and support? 

3- Is structural reinforcement required to accommodate 
system interface? 

Decision IVA-25. System Interface O.K.? 


Are the system interface and structural ccncept 
satisfactory for location, system function, systems 
support, structural efficiency for access, and 
servicing? 


Decision VA-26 . Revise Systems? 


Should the system (location, attachment, support, or 
function) be revis^ for improved system/structiire 
interface? 


Decision VIA-28. Internal Loads Available? 
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Are all internal (static/dynamic) loads available that 
impact the structxire due to systems interface, system 
ftinction, equipment attachment and function, linings, 
etc-? 

Decision VIA— 33- Internal Loads Satisfactory? 

1 - Are the internal loads reasonable in magnitude and 
direction? 

2- Are the internal loads complete and current and 

have all the interface attachments been accounted 
for? 

Decision VI-36. Structiiral Concept Satisf actory? 

Does the structure adequately support the internal 
static, dynamic loads with no deterioration of external 
load-cairying capability or fatigue life? 

Decision VIA— 37. Joint Location Developed? 

Are the joint locations developed for the structural 
element concept? 

Decision VIA— 42. Joint Locations Satisfactory? 

1. Do the joint locations occur at low stress 
locations? 

2. Are the joints located away from interface areas to 
avoid interference? 

3. Do the joints divide the basic structure into 
reasonable sizes for material availability and part 
handling? 

4. Are the joints located to enhance infection? 

Decision VIA— 44- Joint Concept Developed? 

Has a joint concept been developed for the structural 
element being joined? 

Decision VIA-4 9. Joint Concept O.K.? 

1. Does the joint concept adecjuately splice the 

structural elements to effect a smooth stress flow 
without stress concentration? 

2- Is the joint concept practical to mamfacttire and 
install? 
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3. Does the joint, concept adequately address problems 
of fatigue, corrosion, and replacement? 

Decision VIA-50. Revise Joint Concept? 

Can the joint concept be modified to reinforce any 
shortcomings such as stress concentrations, 
manufacturing or installation difficulties, fatigue and 
corrosion potentials, or replcement inadequacies? 

Decision VIA-52. New Joint Concept Reqpiired? 

Will a new joint concept be adequate as to stress flow 
manufacturing ease, fatigue, and corrosion prevention? 

Decision VIA-56. Sizing for Strength O.K.? 

Is the joint concept adequate for slicing the shears 
and mcments in the structiiral member? 

Decision VIA-57- Revise Joint Sizing? 

Should the joint be resized to adequately accommodate 
the shears and moments to be spliced and join the 
structural elements without change in stiffness without 
initiating a fatigue condition or a corrosion potential? 

Decision VIA-59. Sizing for Stiffness O.K.? 

Does the joint concept adequately splice the structural 
element with a continuity of stiffness so as not to 
create a "soft" or "hard" spot in the structural 
assembly? 

Decision VIA-60-. Sizing for Durability O.K.? 

Does the joint concept adequately address fatigue life, 
corrosion resistance, and inspection and replacement 
facilities? 

Decision VIA-64. Sizing for Strength O.K.? 

Is the sizing of the structural elements between the 
joints adequate for the shear and moment loads imposed? 

Decision VIA.-65- Revised Structural Element Sizing? 

Should the structural element between joints be resized 
to accommodate the shears and moment, required 
stiffness, and/or the fatigue resistance required? 

Decision VIA-67. Sizing for Stiffness O.K.? 
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Is the sizing of the structural element between joints 
sufficiently stiff to support major loads and interface 
attachment within deflection limits? 

Decision VIA-68. Sizing for Durability 0.K.7 

Is the sizing of the structural element between joints 
adequate for the fatigue life and durability goails as 
established? 

Decision VIB-3 . Design Appropriate? 

1. Is the design adequate for the loads 
(intemal/extemal) that must be carried? 

2. Do the joints splice the parts adequately within 
acceptable stiffness limits? 

3. Are the joint elements easy to make and install? 

4. Does the design fulfill durability goals? 

5. Are corrosion potentials reduced or handled 
adequately? 

6. Are interfaces (system/structure) accommodated? 

7. Is the part geometry within required envelope? 

8. Are materials selected according to design 
directions? 

9. Is the design compatible with the overall similar 
structural family? 

Decision VIB-9. Engineering Advance Material Release 

(EAMR's) Required? 

1 . Are there any long-lead items of material that 
should be ordered at this time to ensure their 
availability vhen production requires them? Long- 
lead items are forgings, forged blocks, casting, 
large extrusions, etc. 

Decision VIB— 12. EAMR*s Satisfactory? 

1. Are all materials ordered that need to be? 

2- Is the data on the EAMR correct (material, 
quantity, etc.) ? 

Decision VIB— 13- Concept or Procedures Probleiri? 
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1. Is the EAMR form filled oxjt properly? 

2. Is the content of the EAMR correct or according to 
design direction as to what items and material are 
proper to order (i.e., casting, forging, forged 
block, extrusion, etc.)? 

Decision VZB-14. EAMR O.K.? 

1. Do the EAMR*s call for the correct material, grain 
direction, heat treatment, alloy, etc.? 

2. Is the EAMR procedurally correct? 

Decision VIB— 17. Gage Information Required? 

Does the production department need the location of 

major pin joint, hinges, production breaks for tool 

planning and tool design, etc.? 

Decision VIB— 19. Class II Mockup Required? 

1 . Is a mockup required for any of the design area to 
assist design, {e.g., space, fiinction of parts, 
sizing, etc.)? 

2. Are space, arrangement, and function as desired? 

3. Are interfaces adequately accommodated and 
supported without determination of the structure or 
interface? 

Decision VIB-25. Structural Element Design Concept O.K.? 

1. Does the design carry all loads (shears, moments) 
within design limits? 

2. Are stiffness and durability within design limits? 

3. Are materials and coatings according to latest 
approved directions? 

4. Are production requirements (fit, finish, methods) 
adequate for the design use? 

5. Are the designs weight -effective? 

6. Does the weight fall within the projected vieights? 

7. Can the design be built with existing facilities? 

8. Is there an easier concept to build? 
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9. Will a change or consolidation of parts lead to a 
cheaper, eeisier configuration to construct? 

10. Are the materials available to build the design? 

11. Does the part geometry fill or stay within desired 
limits? 

Decision VIB-27. Dpdate Work Breakdown Structure? 

1. Does the WBS adeqpiately describe the design? 

2- Are there additions or deletions to the list items 
to be manufactured? 

Decision VIC— 4. Engineering Drawing Satisfactory? 

1- Does the drawing describe the parts completely? 

2- Are all of the features of the part (material, heat 
treatment, finish, identification, tolerance, 
coatings, quantity) defined? 

3. Are all fasteners identified? 

4. Does the item fit and accommodate interfacing 
structure and systems? 

5. Does the design appear reasonable: similar to 
adjacent designs, esthetically reasonable, etc,? 

6 . Are the components and materials the same as those 
on the EAMR? 

7. Is the design correct gecmetrically? 

Decision VIC— 5. Procedures or Other Problems? 

1- Is the drawing correct according to established 
procedures? 

a) Is list of materials complete and correct? 

b) Is tabular block (usage information) complete 
and correct? 

c) Are notes adequate to complete the description 
of the desired part? 

2. Is the design inadequate for the task it must dor 
a) For strength? 
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b) For weight? 

c) For durability? 

d) For 3 if e? 

e) For producibility? 

f) For cost? 

Decision VIC-13. Drawing Satisfactory? 

1. Does the design carry all loads (sheairs, moment) 
within design limits? 

2. Are stiffness and durability within design limits? 

3- Are materials, heat treatment, coatings, and 
fasteners according to directives? 

4. Are production requirements (fit, finish, methods) 
adequate for design use? 

5 . Are designs weight-ef f ective? 

6. Does the weight fall within projected weight 
limits? 

7. Can the design be built with existing facilities? 
8- Is there an easier concept to build? 

9. Wi3i a change or consolidation of parts lead to a 
cheaper, easier configuration to build? 

10. Are the materials available to build the design? 

11. Does the peurt geometry fili or stay within desired 
limits? 

12. Does the design appear reasonable; similar to 
adjacent designs, esthetically reasonable, etc.? 

Decision VIC-15. Drawing Satisfactory? 

1. Is materials technology staff satisifed with the 
drawing? 

2. Is weights technology staff satisfied with the 
drawing? 

3. Is the stress staff satisfied with the drawing? 
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4. Are the production, planning, material procurement, 
and tooling organizations satisfied vd.th the 
drawing? 

5- Is engineering management satisfied with the 
drawing? 

Decision VII— 2. Production Problem Requiring Redesign? 

1. Have potential problems been identified during the 
manufacturing review? 

2. Which problems could best be solved by changes in 
the engineering definition? 

Decision VII— 5 . Production Problem Requiring Redesign? 

1. Have problems been identified during the design of 
tooling? 

2. Which problems could best be solved ly changes in 
the engineering design definition? 

Decision VII-8. Parts and Tool Satisfactory? 

Have parts and/or tools been rejected? 

Decision VlI-9. Problem Requiring Redesign? 

1. Should parts and/or tools be scrapped or reworked? 

2. Is redesign of the part and/or tool the best 
solution? 

Decision VII-10- Rework or Scrap? 

Can rejected parts be reworked? 

Decision VII-13. Production Problem Requiring Redesign? 

1. Is redesign of the part the best solution? 

2. Can liaison engineering correct problem? 

Decision VII— 14. Product Complete? 

1. Has the queility control as-built audit identified 
any discrepancy from the as-designed definition? 

2. Do exceptions require rework to complete the 

product? 
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Design VXI-16- "As -Built" Same as "As -Designed"? 

Are deficiency reports reqiiired? 

Decision VIII— 5- Problem Requiring Redesign? 

1. Have problCTis been identified during the product 
verification? 

2. Is redesign of parts the best solution? 

Decision G-5. Information Available? 

Is all of the information required available, 
understandable, and in a form that is applicable to the 
task? Can it be separated from other data and 
retrieved? 

Decision G-10. Information Correct? 

Is the information credible; does it withstand testing; 
is it correct and accurate enough for use in this 
design? 

Decision G-12. Information Complete? 

Is all of the information sufficiently coiqplete to 
develop the design? 

Decision G-14. Repeat? 

Should another information item, similar to that just 
gathered, be selected or generated in the same manner as 
the last item? Is more of a similarly developed data 
r equi red? 

Decision G-15- Select or Generate? 

Is the information to be selected from existing data or 
is it to be generated? 

Decision G— 17- Method Available? 

Is there a method/procedxire available to do the tasks 
needed to generate the required data? 

Decision G-22. Information Correct? 

Is the information generated correct or, at least, 
sufficiently accurate to use in the design? Does it 
have a sotmd basis for credibility? 
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Decision G— 24 . Method OK? 


Is the method an acceptable process or algorithm? Is 
the method applicable to the input and output data? Is 
the output accuracy and voliime sufficient for the needs 
of the design or' is a more elaborate method needed? 

Decision G-25. Revise Information? 

Can the information be revised to be correct and 
complete enough for the task requirement? Is the 
information developed too inaccurate and/or too vague to 
be revised? 

Decision G-27. Delete Information? 

Is the information useless for any future use? Has the 
information any real value for some other or future 
task? 



APPENDIX B 


GLOSSARY 


ACCESS CODE 

Access codes wiXl control access to data sets and jobs. 
ACTIVITY 

An activity consists of actions which are associated for any 
reason. An activity is usually accomplished by a group of 
individuals working together for the purpose of close 
coordination. These individuals are normally from one 
discipline, e.g., aerodynamics, structures, etc. The actions 
within an activity are normally the execution of one or more 
jobs. 

CLASSIFICATION CODE 

A classification code is used to identify items classified 
within a uniform classification and coding system. The 
system is based on organizing data in a consistent and 
disciplined manner. Each code is nteaningful and discrete, 
and is a universal index for all information bearing the same 
code. It is useful as a tool for storing, retrieving, 
sorting, analyzing, collating, and identifying data. These 
codes may be used as sorting criteria for the data stored in 
the information bank- 

CODING MODULE 

A specific collection of symbolic code that contributes to 
the definition of one or more operational modules. Coding 
modules are the smallest division of user source code that 
can be defined - 

DATA AREA 

An arbitrary collection of data sets which are grouped 
together for purposes of control, managanent, ease of use, 
etc. 

DATA ELEMENT 

The smallest definable unit of data, i.e. , an entity or item. 
It is not restricted in terms of size or complexity but only 
in that, in an engineering sense (as opposed to computing) , 
the item is referencable as a single entity. 
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DATA FORMAT 


Defines the information bank access method for storage and 
retrieval of a corresponding occurrence of a data set- Also 
defines the indexed structure of the data values contained in 
a defined data set- 

DATA PRIMITIVES 

The basic building blocks for data in the information bank. 
DATA RECXDRD 

A data record is an enumeration of data elements. 

DATA RELATIONSHIP 

A data relationship is a logical grouping of one or more data 
records . 

DATA SET 

Denotes that a specific occurrence of data corresponding to a 
given data format has been generated . A data set may or may 
not be defined to IPAD- 

DATA SET HE7UDER 

Data contained in a data set header is used to identify the 
owner and source of the data set and to control access to the 
values contained in the data set. The header for geometry 
data sets may contain additional information such as element 
type# coordinate system, etc. 

DICTIONARY 

Dictionaries contain definitions of data elements, data 
relationships, data formats, coding modxiles, operational 
modules, and jobs. Each data area may have at most one of 
each of these dictionaries- An information bank may have one 
set of common dictionaries for definitions that are common to 
all data areas. 

DISPLAY FORMAT 

A display format is a special class of data formats used for 
displaying data sets by defined graphical methods, whether 
online or offline - 
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EXPLICIT INPDT/OUTPUT 


Input/outpiit action to or from a data set under the control 
of a viser program. IPAD is responsible only for the data set 
as a unit and, in general, is not capable of interpreting the 
contents of any data set handled in this way. 

The data format for an undefined data set will not specify 
the structure of the data set. 

HOST SYSTEM 

The computer processing system (hardware and software) 
containing the liost IPAD 

HOST IPAD 

The IPAD system software supporting user activity on the IPAD 
information batnk and exercising sole control on the IPAD 
information bank 

HOST USER 

A user who is currently using the host system directly, i.e., 
not using the host IPAD 

HOST IPAD USER 

A user who is currently using the host IPAD 
IMPLICIT INPUT/OUTPDT 

Input/output action to and from a data set which is under the 
direct control of IPAD- The data format for a defined data 
set will speci:^ the structure of the data set. 

INFORMATION BANK 

The domain or collection of all data areas defined to IPAD 

INFORMATION BANK ADMINISTRATOR (S) 

Information administration is a special form of managerial 
control including authority over both data integrity and 
security and responsible for overall efficiency. The 
information bank administgrator is responsible for the overall 
organization of the information bank, its dictionaries, 
program libraries, and security provisions. 
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IPAD C0M4UNICAT10N NETWORK 


The IPAD cGcninunicatian network is defined to include all 
hardware and software furnished and maintained by the IPAD 
contractor or by independent vendors and used to provide 
comiminications between the IPAD host computers and any IPAD 
satellite computer. This includes any translators required 
to reformat data or computer programs for trananission 
between computers - 

IPAD COMPUTER PROGRAM LIBRARY 

The collection of all user— supplied computer programs 
installed into IPAD 

IPAD HOST COMPUTER 

The IPAD host computer includes all hardware and software 
furnished and maintained by the con 5 >uter vendors. 

IPAD SATELLITE COMPUTER 

The IPAD satellite computer includes all hardware and 
software furnished and maintained by the computer vendors and 
used to support CAD /CAM work stations .or any other 
application remote to the IPAD host computer. 

IPAD SYSTEM 

The IPAD system includes aiJ. software designed and developed 
under the IPAD contract and all existing software p\ir chased 
and installed as part of the IPAD system, which shall be 
maintained by the IPAD contractor or subcontractor during the 
program's life. 

JOB 

A specific sequence of interfaced operational nodules and/or 
other jobs that prodixre meaningful results for a user. 

KEY WORD LIST 

The key word list, an impoirtant item for each dictionary 
entry, allows users to search existing diction ai-y entries to 
fulfill their needs. This capability helps to limit the 
number of redundant entries in the dictionary containing the 
same information or having the same mathematical definition. 


LEVEL 

A level consists of activities associated for control by 
management. Levels relate to the degree or depth of the 
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design process . Each level is normally accomplished by 
several disciplines working together to establish a predicted 
confidence level for risk evaluation by managenent. 

OPERATIONAL MODULE 

An executable collection of coding modules contributing to 
one or more jobs 

OPERATING SYSTEM 

The operating system for the host or satellite coiiputer 
within which IPAD or remote (subset) IPAD executes 

PERMISSION CODE 

Permission codes will be equivalent to a managenent system 
within the IPAD command language. The typical user will 
operate with functional capability limits established by 
permission codes. 

PROCESS 

A series of continuous actions planned and defined within a 
hierarchical system of levels divided into activities 
accomplished by executing one or more jobs. Each level has 
forward and feedback data flow paths defined within 
activities and between related activities. Data transfer 
between levels may be forward or feedback. 

PROGRAM ITEM NUMBER (PIN) 

A niimber relating an item of work to the work breakdown 
structure and used as a primary index to work items and for 
cost collection 

PROJECT 

The sequence of tasks and subtasks to be perfoimed during am 
associated design and/or analysis effort 

PROJECT PLAN 

The definition of all project tasks and subtasks and the 
associated control in terms of a network showing schedule 
dependenci es 

PROJECT REPORT 

The collection of reports expected to be generated during the 
progress of a project 
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II 


REMOTE SYSTEM 

Any computer processing system {hardware and software) that 
is remote to the host system. A remote system may or may not 
contain a remote IPAD, i.e., a subset of IPAD. 

REMOTTE IPAD 

A portion or subset of the IPAD system software residing on a 
remote system and supporting remote user activity and 
coordination with the host IPAD and other remote IPAD's 

REMOTE DSER 

A user who is currently using the remote system directly, 
i.e., not using a remote part of IPAD 

REMOTE IPAD DSER 

A user who is currently using a remote part of IPAD 
REMOTE IPAD DATA 

Data stored remotely from the host system in a manner 
compatible with host IPAD control and conventions 

SECURITY CODE 

Security codes are those coded conventions established to 
meet company or governmental rules pertaining to controlling 
access to data. These are a key subset of the total set of 
access codes. 

SDBTASK 

A sequence of jobs using IPAD and representing a meaningful 
step in a project 

SDBTASK DATA AREA 

A data area associated with an IPAD user during the execution 
of one subtask. Each subtask will have an associated subtask 
data area. Idle sxibtask: data area is a private user working 
data area, and all data is generated in a subtask data area. 

SDBTASK STEP 

A single step occurring in a subtask, normally defined by a 
host operating system control card or the execution of a 
single IPAD utility program 
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TASK 


A sequence of sutrtas)cs accomplished by a group (discipline) 
and representing a milestone in the project plan 


USER IDENTIFICATION 

A unique identifier associated with each user of IPAD. This 
ID inust be associated with a person and not with an activity 
or an organization. 

VERSION NUMBER 

A special identification used to denote a specific version of 
a data set or a program 

WORK BREAKDOWN STRUC1*URE (WBS) 

A Structured iniex to all elements of work and all end items 
produced by a product program 
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APPENDIX C 

SI-U.S. CONVERSION TABLE 


METRIC TABLES 
LENGTH 


Myriameter . 

10,000 mettre . 

6.2137 miles. 

Meter. . . . . 

, 1 meter. . . . 

. 39.37 inches. 

Kilometer . , 

1,000 meters. . 

0.62137 mile. 

Decimeter . 

. 0.1 meter. . . 

. 3.937 inches. 

Hectometer . 

100 meters. . . 

328 feet 1 inch. 

Centimeter. 

. 0.01 meter. . 

. 0.3937 inch. 

Dekameter. . 

10 meters . . . 

393.7 inches. 

Millimeter . 

. 0.001 meter . 

. 0.0394 inch. 


AREA 


Hectare. 
Are . . . 
Centiare 


10,000 square meters. . . . 2.471 acres. 

100 square meters 1 19.6 square yards. 

1 square meter 1 ,550 square inches. 


WEIGHT 


Number of Volume corresponding Avoirdupois 

grams to weight weight 


Metric ton, millier or tonneau 1,000,000 

Quintal 100,000 

Myriagram 10,000 

Kilogram or kilo 1,000 

Hectogram 100 

Dekagram 10 

Gram 1 

Decigram ,1 

Centigram .01 

Milligram .001 


1 cubic meter 

1 hectoliter 

1 dekaliter 

1 liter 

1 deciliter 

10 cubic centimeters . 
1 cubic centimeter . . 
0.1 cubic centimeter . 
10 cubic millimeters . 
1 cubic millimeter. . . 


2.204.6 pounds. 

220.46 pounds. 

22.046 pounds. 
2.2046 pounds. 
3.5274 ounces. 
0.3527 ounces. 
15.432 grains. 
1.5432 grains. 

0.1 543 grain. 
0.0154 grain. 


CAPACITY 


Number of 
liters 


Metric cubic 
measure 


United States 
measure 


Kiloliter or stere. . 
Hectoliter 

Dekaliter 

Liter 

Deciliter 

Centiliter 

Milliliter 


1,000 

100 

10 

1 

.1 

.01 

.001 


1 cubic meter 

0.1 cubic meter 

10 cubic decimeters. . . 

1 cubic decimeter .... 

0.1 cubic decime- 
ter. 

10 cubic centime- 
ters. 

1 cubic centimeter . . . 


1.308 cubic yards 

2.838 bushels; 26.417 gal- 
lorts. 

1.135 pecks; 2.6417 gal- 
lons. 

0.908 dry quart; 1 .0567 
liquid quarts. 

6.1023 cubic inches; 0.845 
gill. 

0.6102 cubic inch; 0.338 
fluid ounce. 

0.061 cubic inch; 0.271 
fluid dram. 


1.308 cubic yards. 

2.75 bushels; 22.00 gal- 
lons. 

8.80 quarts; 2.200 gal- 
lons. 

0.880 quart. 

0.704 gill. 

0.352 fluid ounce. 
0.284 fluid dram. 


COMMON MEASURES AND THEIR METRIC EQUIVALENTS 


Common measure 


Equivalent 


Common measure 


Equivalent 


Inch 2.54 centimeters. 

Foot 0.3048 meter. 

Yard 0.9144 meter. 

Rod 5.029 meters. 

Mile 1.6093 kilometers. 

Square inch 6.452 square centimeters. 

Square foot 0.0929 square meter. 

Square yard 0.836 square meter. 

Square rod 25.29 square meters. 

Acre 0.4047 hectare. 

Square mile 259 hectares. 

Cubic inch 16.39 cubic centimeters. 

Cubic foot • • • 0.0283 cubic meter. 

Cubic yard 0.7646 cubic meter. 

Cord 3.625 steres. 


Liquid quart. United States . 0S463 liter. 


Dry quart. United States . . . 1.101 liters. 

Quart, imperial 1 .1 36 liters. 

Gallon, United States 3.785 liters. 

Gallon, imperial 4.546 liters. 

Peck, United States 8.810 liters. 

Peck, imperial 9.092 liters. 

Bushel, United States 35.24 liters. 

Bushel, imperial 36.37 liters. 

Ounce, avoirdupois 28.35 grams. 

Pound, avoirdupois 0.4536 kilogram. 

Ton, long 1 .0160 metric tons. 

Ton, short 0.9072 metric ton. 

Grain 0.0648 gram. 

Our>ce, troy. 31.103 grams. 

Pound, troy 0.3732 kilogram. 
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